Agile Glossary

The specific criteria identified by the customer for each functional requirement. The acceptance criteria, written in easily to understand terms and from the customer’s perspective, provides additional detail into how a feature should work and assesses the ability of the feature to perform its intended function.

Often used as the abbreviation for Agile Software Development or Agile Methods. Agile is a generic term which refers to a collection of light weight software development methodologies that value and support evolving requirements through iterative development, direct Customer/Developer communication and collaboration, self-organizing cross-functional teams, and continuous improvement through frequent inspection and adaption.

Short for Agile Unified Process, it refers to a simplified version of the IBM Rational Unified Process (RUP). Much like RUP, AgileUP is an iterative process, that utilizes several agile techniques and ideas for the purpose of developing business applications. The most noticeable difference between the two processes is that AgileUP only defines 7 key disciplines to RUP’s Those disciplines are:

A burn down chart is a simple, easy to understand graphical representation of “Work Remaining” versus “Time Remaining”. Generally, “Work Remaining” will be represented on the vertical axis while “Time Remaining” is displayed along the horizontal axis. Burn down charts are effective tools for communicating progress and predicting when work will be completed. The burn down chart is also an effective means for teams to make adjustments in order to meet product/ project delivery expectations.

The measurement of how much work can be completed within a given, fixed time frame by estimating the number of available, productive work hours for an individual or team. To accurately estimate capacity, it is important to factor in all known variables such as meetings, holidays and vacations, as well as the effects of multi-tasking and normal administrative tasks.

Complexity points are units of measure, based on relative sizing, used to estimate development work in terms of complexity and/or size, versus traditional time based methods which attempt to measure the duration of time required to complete some unit of work. Complexity Points are similar to ‘StoryPoints’ (see Story Points) but the scale used for complexity points may vary based on the differences in implementation of this sizing approach.

Crystal (sometimes referred to as Crystal Clear) is a lightweight, agile software development framework developed originally by Alistair Cockburn. Crystal, as a basic matter of principle, is primarily focused on the collaboration and interactions between teams of people rather than the processes and artifacts of traditional methodologies. Crystal methods value:

• Frequent delivery of working software.
• Continuous, reflective improvement.
• Osmotic communication via team colocation.
• Technical excellence by utilizing automated testing, configuration management and frequent integration.

The Daily Scrum also referred as ‘daily stand-up’, is a brief, daily communication and planning forum, in which Agile/Scrum teams come together to evaluate the health and progress of the iteration/sprint. It is also considered to be the fifth and final level of the agile planning process. As a daily, team planning meeting, an effective daily scrum should be a tightly focused and time boxed meeting that occurs at the same time and place, on a daily basis. The intent of the daily scrum is to better understand the progress of the iteration, by all contributing team members honestly answering the following three questions:

1. What did I accomplish yesterday?
2. What will I commit to, or complete, today?
3. What impediments or obstacles are preventing me from meeting my commitments?

Conversation in these meetings should remain focused on answering these three questions only. For the sake of brevity and greater team efficiency, additional discussion stemming from these three questions should be handled independently of the daily scrum, and should be limited to those team members who are directly involved.

The Developer Unit refers to the people that are responsible for delivering working software that meets requirements by collaborating with the customer throughout the development lifecycle. Typically, the Development Unit is comprised of individuals fulfilling the technical roles of development (developers, QA, tech writer, project manager, DBA and others), working together in one or more, cross-functional agile teams. In agile projects, the developer unit is responsible for estimating the backlog, working with the customer unit to plan the iterations, iteration execution, demonstration, and ultimate delivery of working software.

Epic stories are user stories whose scope is so large as to make them difficult to complete in a single iteration or accurately estimate the level of effort to deliver. Epic stories, while common when first defining the product backlog (see product backlog), should be decomposed into smaller user stories where the requirements of the story are defined much more narrowly in scope.

Feature based planning is an approach used in release planning, where features and scope take priority over date. Release plans (see Release Planning) created utilizing this approach are created by estimating the amount of time that will be required to complete a certain defined amount of scope. Often this approach is utilized for new product launches where a minimal or critical amount of feature/function must be delivered in order for the completed product to be considered market worthy.

Feature teams are small, cross-functional teams of development resources, focused on designing and building specific feature groupings or areas of system functionality. The feature team concept is utilized by FDD and other agile methods.

The five levels of Agile planning are Vision, Roadmap, Release, Iteration (or Sprint), and Daily. The top level (Vision) represents the “big picture” of the overall effort and thus the planning at this level encompasses more strategic product information and less details on the product specifics. Working through to the bottom level, more details are included in the produced plans, so that in whole, the five levels of Agile planning represents a holistic understanding of what we are building, why we are undertaking the effort, and how we plan to deliver.

Coined by Bill Wake in eXtreme Programing Explored, INVEST is an acronym that defines a simple set of rules used in creating well formed User Stories.

• Independent: Stories should not be dependent on other stories.
• Negotiable: Too much explicit detail regarding particulars and solutions. Stories should capture the essence of the requirement and should not represent a contract on how to solve it.
• Valuable: Stories should clearly illustrate value to the customer.
• Estimable: Stories should provide just enough information so they can be estimated. It is not important to know the exact way that a particular problem will be solved, it must be understood enough to provide a high level estimate.
• Small: Stories should strive to be granular enough in scope that they may be completed in as little time as possible, from a few weeks to a few days.
• Testable: Stories need to be understood well enough so that a test can be defined for it. An effective way to ensure testability is to define user acceptance criteria for all user stories.

Lean Software Development, which is rooted in the Lean Manufacturing techniques developed by Toyota, is another popular example of a light-weight agile approach to product development. Much like other agile methods, Lean attempts to address the short comings of traditional software project management methods by focusing on people and effective communication. Lean is further defined by the following seven key principles:

• Eliminate Waste: Understand your customers needs and seek to deliver solutions that address only those needs as simply as possible.
• Create Knowledge: Create a team based environment in which all individual participate in the design and problem-solving process.Create a culture that encourages constant improvement through regular inspection and adaptation.
• Build Quality In: Embrace re-factoring and test automation and test driven development. Understand your test requirements and plans before you begin coding.
• Defer Commitment: Avoid dependencies by embracing loose coupling. Maximize flexibility by narrowly defining requirements and schedule irreversible decisions to the last possible moment.
• Optimize the Whole: Focus on the entire value stream. Understand that a completed product is the sum of the all the various contributors and the result of effective collaboration.
• Deliver Fast: Reduce risk and volatility by limiting scope.Commit only to work for which you have the capacity to complete. Decompose work to discrete actionable tasks and releasework often and iteratively.
• Respect People: Trust that your people know best how to do their jobs and empower them to make the decisions needed to complete their commitments.

MoSCow is a feature classification/categorization method, rooted in rapid application development, that is commonly utilized in agile projects. The method is intended for short, time-boxed development Sprints where focus should remain on those items that are deemed most critical for delivery within the time-boxed period. MoSCoW itself is a modified acronym, that represents 4 different levels of priority classification.

• Must Have – These are time critical project requirements that must be delivered in order for the project not to be considered an outright failure. These are generally baseline, or critical path features.
• Should Have – These are also critical project level requirements, however they are not as time critical as Must Have requirements.
• Could Have – These are considered to be the Nice to Have requirements. Features that are not necessarily required for the success of the iteration or project, but features that would increase end-user/customer satisfaction in the completed product.
• Won’t Have – These are lowest priority requirements that will not be scheduled or planned within the delivery time box.

A fictional character that is created to represent the attributes of a group of the product’s users. Personas are helpful tools to use as a guide when deciding on a product’s features, functionality, or visual design. Personas allow a team to easily identify with a fictional version of the product’s end users.

Planning poker is a team based exercise that is commonly used for assigning relative estimate values to user stories/ requirements to express the effort required to deliver specific features or functionality. The game utilizes playing cards, printed with numbers based on a modified Fibonacci sequence (0,1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100). Equipped with playing cards, all members of the development unit team and the product owner meet together to discuss product backlog requirements for the purpose of reaching a consensus based estimate. The rules of the game are as follows:

1. The team and the product owner select from the backlog a requirement that all agree is small enough in size and complexity to be considered as 2. This becomes the baseline requirement.
2. With the baseline requirements selected, the product owner selects a requirement from the backlog and describes it greater detail, allowing the team to ask any clarifying questions. Discussion regarding the requirement should be limited in time to 5-8 minutes.
3. Once everyone on the team is satisfied with the details, each player pulls a numbered card from their deck that they feel best represents the current requirements size and complexity relative to the baseline requirement or other known, estimated requirements. This card is placed face down.
4. Those players with high and/or low estimates are asked to justify their selection by discussing with the team.
5. After the outliers have justified their selections, the team repeats the estimation process until group consensus achieved.
6. This process is repeated as much as needed in order to score all requirements from the backlog.

Often referred to as the “Voice of Customer” on agile projects or the “Product Manager” on traditional projects, the product owner is the person responsible for communicating the customer requirements. While considered part of the customer unit, the product owner role is critical to the success of an agile product development effort. In addition to communicating requirements, the product owner is responsible for defining user acceptance criteria for requirements, prioritizing and managing the product backlog, as well as collaborating with the development unit throughout the iterative development cycle.

Created by Rational Software (which was later acquired by IBM), the Rational Unified Process (RUP) is an iterative development process that seeks to increase development agility by providing a flexible, best practice based life cycle management framework. RUP prescribes the utilization of 9 key disciplines extended across 4 main project phases. Those phases are:

1. Inception Phase.
2. Elaboration Phase.
3. Construction Phase.
4. Transition Phase.

The 9 key disciplines are as follows:

1. Model. The goal of this discipline is to understand the business of the organization, the problem domain being addressed by the project, and to identify a viable solution to address the problem domain.
2. Requirements. The goal of this discipline is to elicit stakeholder feature/function requirements in order to define the scope of the project.
3. Analysis and Design. The goal of this discipline is to define the requirements into actionable and executable designs and models.
4. Implementation. The goal of this discipline is to transform your model(s) into executable code and to perform a basic level of testing, in particular unit testing.
5. Test. The goal of this discipline is to perform an objective evaluation to ensure quality. This includes finding defects, validating that the system works as designed, and verifying that the requirements are met.
6. Deployment. The goal of this discipline is to plan for the delivery of the system and to execute the plan to make the system available to end users.
7. Configuration Management. The goal of this discipline is to manage access to your project artifacts. This includes not only tracking artifact versions over time but also controlling and managing changes to them.
8. Project Management. The goal of this discipline is to direct the activities that takes place on the project. This includes managing risks, directing people (assigning tasks, tracking progress, etc.), and coordinating with people and systems outside the scope of the project to be sure that it is delivered on time and within budget.
9. Environment. The goal of this discipline is to support the rest of the effort by ensuring that the proper process, guidance (standards and guidelines), and tools (hardware, software, etc.) are available for the team as needed.

A test completed to validate previously completed and tested code. The regression test is performed in an effort to ensure that subsequent deliveries of code segments have not corrupted previously completed code. These tests are also often performed after defects are remediated to ensure that the fixes have not corrupted any other portion of the software.

A release plan is a document that further distills the roadmap by describing all of the anticipated activities, resources, and responsibilities related to a particular release, including the estimated duration of that release. Unlike in traditional waterfall managed projects, agile methods seek to ensure the highest degree of plan accuracy by encouraging regular and iterative re-planning based on actual iteration results. Additionally, release planning is considered to be the third level in the five level agile planning process.

The roadmap (or product roadmap) is a document that further distills the product vision as defined in the product charter into a high level plan. Commonly, the roadmap will attempt to outline project work that spans one or more releases, by grouping requirements into prioritized themes and estimating the execution schedule against said themes. Additionally, roadmap is considered to be the second level in the five level agile planning process.

Scrum is an incremental and iterative software development framework, and is arguably one of the most commonly used agile methods. Unlike other agile methods, scrum is not an acronym. The method was coined as such by Hirotaka Takeuchi and Ikujiro Nonaka in a HBR article titled ʻThe New Product Development Game’ written in 1986, in reference the sport of rugby. The process involved was developed by Ken Schwaber and Dr. Jeff Sutherland.

Scrum outlines a process framework in which Product Owners, Scrum Masters and Team Members, all work together collaboratively to define product and sprint backlogs that are executed in short, time-boxed iterations that are called sprints. At the end of each sprint, a working increment of the software is delivered/demonstrated to the product owner and the entire process repeats itself.

Similar in intent to the Daily Scrum (or Daily Stand Up), the Scrum of Scrums is a daily communication forum commonly used in larger projects utilizing multiple scrum teams. As more teams are introduced, the likelihood of intra-team impediments due to overlapping work and dependencies increases. The Scrum of Scrums is an effective way of managing these impediments. Typically, this meeting occurs after all of the individual team scrum meetings have been completed. An individual from each scrum team (usually the scrum master) is tasked with representing the scrum team in this meeting. The agenda of this meeting is virtually identical to that of the daily scrum, other than the three questions are modified slightly to better reflect the focus on teams.

1. What did my team accomplish yesterday?
2. What will my team commit to, or complete, today?
3. What impediments or obstacles are preventing my team from meeting its commitments?

Often also referred to as an Iteration, a sprint is a predefined, time-boxed and recurring period of time in which working software is created. The most commonly used sprint durations are 2, 4 and 6 week periods. The sprint level is also considered to be the fourth level in the five level agile planning process.

Note: The terms Sprint and Iteration are synonyms and are effectively interchangeable. The term sprint is widely used by teams that identify their agile approach as Scrum, whereas iteration is a more generic term used in the same manner.

Often also referred to as the Iteration Plan, the sprint plan is the detailed execution plan for a given (usually current) iteration. It defines the iteration goals and commitments by specifying the user stories, work tasks, priorities and team member work assignments required to complete the iteration. The Sprint Plan is normally produced by the entire development unit during the sprint planning session.

Story points are unit-less measures of relative size assigned to requirements for functionality. Story points are assigned by the entire team utilizing the planning poker exercise. Story points allow the team to focus on the pure size and complexity of delivering a specific piece of functionality rather than trying to perfectly estimate a duration of time required for the completion of the functionality.

The concept that developers should not work an excessive number of hours due to the possibility of “developer burnout.” Reflects studies that have determined the team productivity greatly decreases when teams work in excess of 40 hours per week. Teams working at a sustainable pace are more effective in accurately predicting their capacity over time while also maintaining the quality of their deliverables.

Simply put, a team member is anyone on a scrum team who is not a Product Owner or Scrum Master, who is responsible for specific iteration deliverables and is accountable for contributing to team iteration commitments and goals. A team member may be a developer, a technical writer, an architect, quality analyst or any other role essential to the production and delivery of working software.

More a technique than an actual development methodology, test driven development, often abbreviated as TDD, is a practice that is commonly utilized in agile methods. TDD advocates the discipline of building working code, by first designing and building tests that exercise how the completed code should work, then creating the code so as to make all the pre-defined tests pass. The idea being that if a developer first understands the tests required to validate how the code should work and when it is complete, that developer will be much more thoughtful and successful in designing and developing working, quality software. While TDD promotes the utilization of automated testing tools combined with version and source code control tools, automation should not be considered a strict requirement as there is still considerable value in simply following the basic, quality driven principles of TDD.

A use case is a document that attempts to describes system behavior from an end-user’s perspective, by outlining the flow of data, system behavioral interchanges and corresponding end-user interactions in a sequential, step-by-step manner. While there is no single standard or format that they must follow, and use cases should vary in detail based on the needs of the requirements, uses cases often make use of the following artifacts to describe how a system should work.

• Goal – What is end goal and desired effect of the functionality that the use case is attempting to describe.
• Summary – A brief, high-level and easily understood description of the use case.
• Actors – The consumers of the system that will be interacting with the system within the scope of the use cases. Actors can be people or other systems or services.
• Preconditions – System conditions and assumptions that must be true for the use case to be valid.
• Triggers – The specific events required to initiate the use case.
• Body Text – The description of each of the steps involved/ required to complete the use case. Generally, body text will focus only the main (happy) path.
• Alternative Path – Steps that deviate from the main path due to exceptions, alternative logic or other conditional events.
• Post Conditions – The changes in the system and data as a result of executing steps outlined in the use case.

A key ingredient in defining agile requirements, user roles are used to describe the unique perspectives of the different consumers that will interact with the working software. Much like actors in a use case, user roles should not just be limited to the human consumers of the software and should also include any other relevant external software or service.

Used in combination with relative (story point) estimation, static teams, and fixed time-boxed iterations, velocity is a predictive metric that is useful for long/mid-term planning and estimation. Simply put, velocity attempts to measure the number of story points a single team can complete within a single, time-boxed iteration. Assuming that all of the requirements in a product backlog have all been estimated using a similar relative estimation point scale, it becomes possible to estimate the number of time-boxed iterations required to complete said backlog by simply dividing the team velocity value by the sum of the backlog’s complexity point total.

The term used to describe the level of completeness that features developed during an iteration should achieve by the conclusion of the iteration. Working software implies that the features demonstrated to the customer at the end of an iteration should be functionally complete and will not require redevelopment in order to prepare the functionality for a production environment.

Used in one of the 12 Agile Principles
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.