Glossary

A/B testing A common practice to compare two ideas for effectiveness. Web sites, for example, might have two home pages that are presented to visitors on a random or targeted basis, and the actions taken from the two pages are measured to determine which one drives the desired behavior.

Acceptance criteria An indication of what is needed for a user story to be considered complete.

Acceptance tests Acceptance tests are performed to ensure that the product functions meet the agreed-upon requirements. They can be performed by the test team when acting as a mock customer, or by a customer before formally accepting a contracted product.

Accountability Accepting the consequences of your actions, whether good or bad.

Adaptive software development (ASD) An Agile methodology that focuses on speculation, collaboration, learning, and adapting the process to the work at hand.

Agile An umbrella term for a group of methodologies that follow the values and principles captured in the Agile Manifesto. Scrum is an example of an Agile methodology.

Agile Manifesto A philosophical foundation for effective software development, the Agile Manifesto was created by representatives from several Agile methodologies. It reads as follows:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Alpha tests Tests that allow customers to try early versions of the code to provide feedback to the product team.

Automated testing Testing that uses software that is independent of the software being testing to execute tests without human intervention and compare the results against the desired outcome.

Backlog See Product backlog or Sprint backlog

Behavior-driven testing A tool that tests the behavior of a product. The test code is written in “business readable language,” meaning the test language can be read and understood by team members who are not familiar with programming languages.

Beta tests The soft launch of a new product or features to a select group of people to gather feedback.

Beta users The customers who participate in a beta test or soft launch. In return for their candid feedback, they usually receive the product at a discount, or even for free.

Big bang This refers to a large program, project, or campaign that is unveiled when it is completed. Agile does not advocate a big-bang approach because we want to deliver frequently and collect feedback at regular intervals.

Big boss A role in XP assigned to the person who holds the team accountable and ensures that they do what they say they are going to do.

Bottleneck A point in the workflow where tasks queue up because there are not adequate resources to handle the workload. This is a form of waste that Lean principles address.

Brand management The conscious caring for the desired feelings and expectations that customers and prospects associate with a product.

Bugs See Defects

Build status When developers add new code to an existing code base, they complete a “build,” and the build status shows if the added code broke any of the existing functionality.

Burn-down chart A chart showing how much work is remaining in the sprint.

Burn-up chart A graphical representation that shows work completed, such as the number of story points, for the project or release.

Business analyst (BA) A role, often in IT, of someone who clarifies requirements and assists with testing. A BA is usually not a developer but can be very useful on a team.

Business value This is a qualitative measure of the value that a particular effort will bring to the business; it could be increased revenue, decreased costs, improved customer experience, efficiency improvement, and much more. Business value is used to determine priority.

Cadence Represents the flow or rhythm of events and the pattern in which something is experienced.

Campaigns Typically refers to marketing efforts designed to attract a target market and drive them toward a purchase.

Change control A term often associated with Waterfall, this is the activity taken to modify the scope, date, or resources of a project; this process is put in place to ensure that changes are known, considered, and documented. Agile incorporates responses to change in the methodologies without a rigid process.

Chickens and pigs Refers to a cartoon about commitment: Chickens are involved in Agile efforts, but pigs are committed. For example, a stakeholder is a chicken; a developer is a pig.

Child story A smaller, more detailed user story that is created by breaking down an epic (parent story).

Classes A breakdown of architecture, systems, or sections of code within FDD, so specific developers work on specific classes of software, as opposed to the collective ownership of code used by XP and Scrum.

Coach An Agile coach guides an organization or team through an Agile transformation. In XP, a coach is someone who mentors and guides the team.

Code kata Programming exercises that help you practice your art through exercises and repetition. The word “kata” comes from the Japanese term for practicing detailed patterns of movement.

Collaboration The action of soliciting input and incorporating the ideas and opinions of others into the planned activity.

Continuous flow This is the way that Kanban projects progress, because an unpredictable stream of work comes into the team. With Scrum, in contrast, where the work progresses in a time-boxed fashion, there is a distinct start and end to a sprint.

Continuous improvement The activities in Agile that lead to getting smarter, more disciplined, and constantly learning, even through mistakes.

Continuous integration A software engineering practice in which isolated changes are immediately tested and reported on when they are added to a larger code base. The goal is to provide rapid feedback, so that if a defect is introduced into the code base, it can be identified and corrected as soon as possible. The usual rule is for each team member to submit work on a daily (or more frequent) basis and for a build to be conducted with each significant change.

Coupling The extent to which a program module depends on other modules within the program.

Course-correct Making modifications in your work, practices, or behavior based on new information.

Crowd sourcing The activity of gathering feedback from a broad group of people, typically through the use of social media, to gain more diverse input than typically comes from traditional customers or users.

Crystal A family of Agile methodologies (Crystal Clear, Crystal Yellow, Crystal Orange, etc.) whose unique characteristics are driven by several factors such as team size, system criticality, and project priorities. It addresses the realization that each project may require a slightly tailored set of policies, practices, and processes in order to meet its unique characteristics.

Culture The behaviors and practices that exist within an organization as the way to get things done; often these are unspoken norms that drive actions. Changing a culture is one of the challenges of an Agile implementation.

Customer council A reoccurring collaboration meeting where the development team meets with the customers to review ideas or working code.

Cycle time The time required to complete a cycle of an operation. It represents the point at which a request was initiated to the time in which it has been completed (delivered into production).

Daily scrum A short meeting (approximately 15 minutes) to share progress, report impediments, and make commitments.

DEEP An acronym coined by Mike Cohn describing a good product backlog: It is Detailed appropriately, Estimated, Emergent, and Prioritized.

Defect An item not functioning as stated in acceptance criteria or a test plan. “Defect” and “bug” are often used interchangeably.

Defect backlog The total number of defects that have yet to be fixed for a product.

Definition of “done” This is an Agile concept where the team agrees on what is considered “complete” before starting the work. Each team might have a slightly different definition of “done,” which might include, for example, peer review or documentation. Every Agile team should include designing, coding, and testing in their definition of done.

Delight A desired state, from the Kano model, where customers are delighted with unique, value-added, and unexpected features in a product.

Demo See Sprint demo

Discovery An activity to solicit input from people about desired functionality or process improvements. Discovery could take the form of interviews or focus groups, for example.

Driver The team member who is writing the code during a paired programming session.

Dynamic System Development Method (DSDM) An Agile methodology based on the nine key principles that primarily revolve around business needs/value, active user involvement, empowered teams, frequent delivery, integrated testing, and stakeholder collaboration. Fitness for business purpose is the primary criterion for delivery and acceptance of a system, focusing on the useful 80% of the system that can be deployed in 20% of the time.

Epic A large user story that will take weeks or months to implement. An epic may also be referred to as a “parent story.”

Estimation The process of agreeing on a size for the stories in a product backlog. This is done by the team, often by using planning poker. Also referred to as “sizing.”

Extreme Programming (XP) An Agile methodology that promotes high customer involvement, rapid feedback loops, continuous testing, and close teamwork to deliver working software at very frequent intervals. Based on four simple values—simplicity, communication, feedback, courage—and 12 supporting practices.

Face-to-face communication One of the core tenets of Agile, advocating that people speak directly to one another so nonverbal cues can be received—such as body language and tone of voice—which might be lost or misinterpreted in an e-mail, for example.

Feature Describes capabilities identified by the stakeholder that provide some value for that person, typically accomplished in one or more stories.

Feature-Driven Development (FDD) An Agile methodology that is a model-driven, short-iteration process. It begins with establishing an overall model shape. Then it continues with a series of two-week “design by feature, build by feature” iterations. These features are small but useful in the eyes of the client. The rest of the development process is designed around feature delivery using eight practices.

Feedback Input from stakeholders and users about a system, workflow, idea, etc. Feedback is often opinions, not necessarily supported by data, but important nonetheless.

Fibonacci sequence A nonlinear number series (1, 2, 3, 5, 8, 13, 21, 34, 55, etc.) where the next number is derived by adding the previous two. This is used by development teams when sizing user stories, though most teams use a modified sequence.

Fist of five A process for determining agreement. When decisions need to be made, all team members hold up one to five fingers to show level of agreement. If anyone is below a three, the decision is discussed further until the entire team agrees with a three or above.

Focus group A targeted group of users or prospects that are asked questions and given information about future product features as a means of gathering qualitative feedback.

Framework for Integrated Test (FIT) Syntax for behavior-driven testing created by Ward Cunningham.

Frequent delivery One of the primary objectives of Agile is the frequent delivery of working software so that the team can collect feedback and adjust if necessary.

Gantt charts A method of measuring project progress as a percentage of completion. Agile adapts to changing requirements, so Gantt charts are seldom used because they are more relevant when the scope is fixed.

Gherkin A language used to write behavior-driven acceptance tests.

Grooming See Product backlog grooming

Human–computer interaction (HCI) The science of how people and systems can most optimally interact.

Ideal time (hours, days) The amount of time a task would take under ideal circumstances with no interruptions, phone calls, meetings, etc.

Impediment Anything that prevents the team from meeting their potential. The Scrum master is responsible for removing impediments, or escalating an impediment if necessary.

Implementation size story A user story that can be completed within the duration of a sprint or iteration. This is sometimes referred to a “child story” and is often created by breaking down an epic into smaller pieces.

Information radiators Data or graphs posted in the team members’ physical space that are seen on a regular basis.

Integration build A build that pulls together code from various parts of the product to create the integrated product.

INVEST A model for writing good user stories based on the idea that they are Independent, Negotiable, Valuable, Estimatable, Small, and Testable.

Iteration A period of time, usually one to four weeks, in which the development team codes and tests one or more small features, resulting in potentially releasable software. “Iteration” and “sprint” are often used interchangeably.

Kanban A tool derived from Lean manufacturing and associated with the branch of Agile practices loosely referred to as Lean software development. Like a task board, Kanban visually represents the state of the work in progress; but unlike a task board, it constrains how much work in progress is permitted to occur at the same time (see Work in progress limits). The purpose of limiting the work in progress is to reduce bottlenecks and increase throughput by optimizing the segment of the value stream that is the subject of the Kanban. A principal difference between Kanban and Scrum is that Scrum limits the work in progress through time boxing (e.g., the sprint) and Kanban limits work in progress by limiting how much work may occur at one time (e.g., X number of tasks or stories).

Kano model A categorization method for customer needs starting with basic needs, moving to performance needs, and finally delighting the customer with unique, value-added, and unexpected functionality.

Kata See Code kata

Lean A term coined in manufacturing processes and applied to software development and IT operations. The main principle of Lean is eliminating waste. See Waste for more.

Lean software development An Agile methodology that owes many of its principles and practices to the Lean enterprise movement. Lean software development focuses the team on delivering value to the customer and on the efficiency of the “value stream,” the mechanisms that deliver that value.

Level of effort (LOE) Specifies the expected amount of activity required to accomplish the task; sometimes used in early stages of estimation.

Manual testing Testing that requires a human tester, who must progress through each step or look over the product to make sure nothing about the code or design is defective.

Metrics Quantitative measures to determine success.

Microtests Individual unit tests that run while the code is being developed. They test an individual behavior in a single object.

MoSCoW An acronym used in DSDM to represent how features or actions should be prioritized: Must have, Should have, Could have, and Want to have.

Multivariant testing The same concept as A/B testing, but with more than two variables.

Mura, muri, muda See Waste

MVP (minimum viable product) A term used in Lean software development: the minimum features needed to address a problem in the marketplace.

Nonverbal Unspoken communication, such as body language, eye contact, fidgeting, and other cues to how a person is feeling, which might contradict what he or she is saying.

Observer The team member who is watching and offering suggestions to the driver during a paired programming session.

On-target testing When the development team is building code to run on a specific device, hardware, or an embedded component of some larger system, it is necessary that the project have tests that run on the actual target hardware.

Pair programming An Extreme Programming approach where two programmers sit side by side, using a shared workstation, to develop code. The pair consists of a driver and an observer.

Parent story The original “epic” size user story that has been broken down into one or more child stories.

Parking lots A tracking mechanism used in FDD for large projects. It is a visual representation of a broad scope so stakeholders can easily assess progress and areas of concern.

Persona A fictional user or customer of the system, used to help guide the prioritization, user experience, and features.

Pigs and chickens See Chickens and pigs

Pilot Another term for “soft launch” or “beta test.”

Planning poker A game used during the estimation phase, where the team has playing cards with story points on them. After learning of a new user story and asking all necessary questions, the team members “throw” the cards that represent their viewpoints of the story size. Any discrepancies are discussed to ensure that everyone has a common understanding.

Portfolio management A portfolio is usually a collection of related projects whose management is complex because of multiple teams and interdependencies.

Pragmatic Marketing An organization (http://www.pragmaticmarketing.com) that provides best practices and certifications to product managers.

Priorities Priorities dictate the relative order of importance of actions. In Agile, priorities are set according to the business value anticipated by the organization.

Product backlog A prioritized list of user stories that the product owner would like completed.

Product backlog grooming A collaborative process to prepare the product backlog for sprint planning; this may include breaking down stories into smaller stories, writing new stories, improving poorly written stories, estimating stories, adding acceptance criteria, or doing longer range technical planning.

Product owner The person who holds the vision for the product and is responsible for maintaining, prioritizing, and updating the product backlog.

Project champion Term often used in DSDM for the project sponsor.

Project management office (PMO) This is the organization where project managers typically report. Many organizations have disbanded their PMO as the teams gain authority and responsibility.

Project sponsor The position in the organization with the authority and budget to allocate financial and human resources to a project. The project sponsor is typically the key executive stakeholder for an Agile effort.

Protoype A rudimentary working model of software or a product that can be demonstrated and used for gathering input.

Public commitment A planned goal or promise made to other individuals, which typically leads to a higher degree of success.

Quality assurance (QA) Testing activity that takes place within a sprint or iteration. The tester typically develops test plans, which are influenced by the acceptance criteria. These test plans are executed against the code, and defects are reported to the developer.

Rational unified process (RUP) An Agile methodology that provides an adaptive framework for individual projects.

Refactoring Constantly improving a product’s internal design (i.e., rewriting code) without changing its behavior to make the product more reliable and adaptable.

Regression tests Testing to see if new code has broken code that already exists in the product.

Relative sizing An estimation technique where a previous effort is used as the baseline and new efforts are compared to it.

Release The transition of an increment of a potentially shippable product from the development team into routine use by customers. Releases typically happen when one or more sprints have resulted in enough product value to outweigh the cost to deploy it.

Release management or release planning The activity of organized release scope and dates to meet the needs of the business and the marketplace.

Retrospective meeting A session where the team and the Scrum master reflect on the process and make commitments to improve.

Rework The action of redoing something after it has been completed due to new information or lessons learned. In the Waterfall methodology, rework had a negative connotation because it indicated error; in Agile, rework is a natural consequence of continuous improvement.

Roadmaps A tool product owners and product management use to share the release plan to customers and stakeholders.

Scalable Agile Framework (SAFe) An Agile software development methodology created by Dean Leffingwell that helps teams scale Agile and Lean techniques to enterprise scale.

Scope The breadth of requirements to be considered in a project. As the project scope grows, the time it will take to deliver may be extended, or additional resources may need to be added.

Scrum An Agile methodology that provides a framework for the iterative development of complex products, particularly software. Scrum is composed of a series of short iterations, called “sprints,” each of which ends with the delivery of an increment of working software.

Scrum master A servant leader to the team, who is responsible for removing impediments and making sure the process runs smoothly so the team can be as productive as possible.

Scrum team A cross-functional group that is responsible for delivering the software or product. The Scrum team is encouraged to be self-organizing and to take collective responsibility for all work commitments and outcomes. Scrum teams respond to requirements (often presented as user stories) by collectively defining the tasks, task assignments, and the level of effort estimates.

Self-managing team See Self-organizing team

Self-organizing team A team that is provided a goal and allowed to work together to determine the best way to reach that goal instead of being told how to reach it.

ShuHaRi An Aikido term meaning “to learn a skill or technique.” First you are in the “Shu” phase, when you must mimic your teacher precisely to master the basics. Next is “Ha,” where you start to learn from other teachers that help you build on your skills, and you begin to gain knowledge about the history and theoretical basis for the technique. Finally, you reach the “Ri” phase, where you become the teacher and make new contributions to the technique.

Silos Organizational boundaries that inhibit collaboration.

Simplicity Striving to find the least complex or the minimalistic solution to the problem or opportunity.

Sizing An estimating technique that defines the relative measure of the effort involved with delivering a particular story. Also referred to as “estimating.”

SME See Subject matter expert

Soft launch Presentation of a product or feature to a small group of customers to gather initial feedback and impressions.

Software development (engineering) Systematic, disciplined, and quantifiable approaches to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.

Spike A story or task aimed at answering a question or gathering information, rather than at producing shippable product.

Sprint An iteration of work during which an increment of product functionality is implemented.

Sprint backlog A list of the tasks necessary to complete the sprint. Tasks are defined by the team.

Sprint demo or sprint review At the end of an iteration, the team will demonstrate the working software that they just developed. This is an informal meeting, open to everyone, including external stakeholders. The team receives feedback, which is used to influence future sprints.

Sprint goal Also known as “sprint theme”; the focus of the work for a single sprint.

Sprint planning meeting A meeting between the team and the product owner to plan the sprint and agree on the commitment.

Sprint retro See Retrospective meeting

Stakeholders These are people who are either directly or indirectly affected by the project. Internal stakeholders are inside the company and could range from users of the system to the CEO, depending on the size and scope of the project. External stakeholders are outside the company, and could range from users of the system to shareholders of stock in the company.

Stakeholder feedback sessions See Sprint demo

Stoplight charts A visual representation of project health; green indicates smooth progress, yellow indicates that risk factors need to be tracked, and red means the project is in trouble and needs intervention.

Story See User story

Story points The Scrum unit of measurement for estimating complexity of user stories; an arbitrary measure Scrum teams use to measure the effort required to implement a story. The number tells the team how hard the story is; “hard” could be related to complexity, unknowns, and/or effort. The Fibonacci sequence is often used to “point” stories.

Subject matter expert (SME) A person with deep knowledge of a system or process; SMEs are often key contributors to projects.

Survey A tool used to validate an assumption or hypothesis by querying many people to solicit opinions and impressions. The data is accumulated in the hopes of finding statistically valid trends.

Sustainable development One of the Agile principles, sustainable development means that you are not overworking the team, so they can maintain their pace over an extended period of time.

System tests Testing all components of the product together on all supported platforms, emulating the customer experience.

Task User stories are broken down into tasks during the Sprint planning session, and the team selects the ones that they are going to “own.”

Task board A visual display of how work is progressing. Typically shown in grid form, where the columns represent the work stages (i.e., Design, Development, Testing), and items are moved across the board as the effort progresses. Task boards are commonly used with Scrum and are essential in Kanban.

Teamwork The ability of a group of people to act as a cohesive unit.

Technical debt Includes those internal things that the team chooses not to do now, but which will impede future development if left undone. There are two kinds of technical debt: Unintended technical debt is simply the consequences of the team’s learning curve; intentional technical debt is incurred as trade-offs are made in the development process, such as choosing to write something quickly but suboptimally so the team can learn as they go. Technical debt also includes deferred refactoring.

Technical excellence One of the principles of Agile is to strive for technical excellence, which includes well thought-out architecture and design decisions as well as quality and discipline in your practices and preparation.

Test cases Repeatable scenarios to test existing and new functionality to ensure that the code works as designed and does not cause problems with any existing functionality.

Test-driven development (TDD) An Extreme Programming approach that requires developers to first write automated test cases, then write only the code necessary to make the test cases pass with no issues.

Time-boxed A term commonly used with Scrum or other methodologies where the work progresses over a predetermined time period, such as a two-week sprint. This contrasts with Kanban, which is referred to as “continuous flow,” since there is no start or end date to a Kanban project.

Tracker Within XP, the tracker is the role that ensures that the project stays on track, often checking in with the development team daily.

Transparency Openly sharing the details of an effort, including progress, roadblocks, concerns, risks, and successes.

Transparent development Product code is made available to customers on a server at all stages of development so they can provide feedback anytime they wish.

Triple constraint A term commonly used in project management to refer to the interdependencies between scope, time, and resources. If you lose resources on a project, for example, you need to either reduce the scope or extend the time.

Trust This is the belief that your teammates will take the best course of action when faced with a decision, even if you are not there to participate.

UED User experience designer—See UX/UI designers.

Usability The ease with which an application can be used.

Use cases A process flow or action that will be taken by a user of the system. Use cases are part of the requirements in RUP.

User acceptance testing (UAT) The process of verifying that a solution works for the user; it is not system testing and is not performed by the development or Scrum team. Some teams include UAT in their definition of done. This is also referred to as “business testing.”

User story A requirement, feature, and/or unit of business value that can be estimated and tested. Stories are the basic unit of communication, planning, and negotiation between the Scrum team, business owners, and the product owner. Stories consist of the following elements:

A description, usually in business terms

A size, for rough estimation purposes, generally expressed in story points, such as 1, 2, 3, 5, 8, and 13

An acceptance test, giving a short description of how the story will be validated

UX/UI designers User experience designers (or user interface designers), the people with background and education in the area of usability or the user experience.

Validation An activity where qualitative feedback, typically gathered in discovery, is quantified with activities such as surveys.

Value stream mapping An exercise where the process flow is mapped entirely from the customer’s perspective to identify where value is added and removed.

Velocity The rate at which a team completes work, often measured in story points.

Vision A conceptual idea of how things should be at some point in the future.

Waste Eliminating waste is the top priority of Lean. The manufacturing (and Japanese) origins refer to three kinds of waste:

Muda—an activity in the process that adds no value

Mura—waste generated by unevenness in operations

Muri—overburdening the people or equipment in this system with more work than they can reasonably manage

Waterfall In Waterfall methodology, software development is done in a linear or sequential fashion: A task cannot begin until the one before it is completed.

Wide-band Delphi A form of estimation where participants anonymously write their size estimates on cards, and the moderator shares the estimates with the group; differences are discussed and the process is then repeated. It is a more formal and structured way to perform estimation.

Wireframes A visual depiction of a process flow that helps users can get a feel for workflow and usability before code is written. Sometimes referred to as “blueprints” or “skeletons.”

Work in progress (WIP) limits A characteristic of Kanban to assign explicit limits to how many items may be in process at each workflow state. This helps to identify bottlenecks and streamline the process.

Working agreement A set of rules that every person on the team agrees to follow. This is created and maintained by the team and can be brought up for discussion in the retrospective meeting.

Working software The goal in Agile is to deliver working software on a frequent basis. Working software has been designed, developed, and tested and is ready to go into production.

XP (Extreme Programming) An Agile methodology that promotes high customer involvement, rapid feedback loops, continuous testing, and close teamwork to deliver working software at very frequent intervals. Based on four simple values—simplicity, communication, feedback, courage—and 12 supporting practices.

XP planning game A form of backlog grooming used in Extreme Programming where the team considers priorities, levels of effort, and complexity to plan the work. The activity consists of the exploration, commitment, and steering phases.

Yesterday’s weather A term used for a calculation of team velocity, considering only the most recent sprints and using the assumption that as a team’s performance improves, only the most recent data is relevant for estimating  future velocity.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.227.183.234