Agile

This category focuses on Agile-Scrum methodology, specifically important Scrum events and artifacts. By the end of the category, you will understand what occurs during sprints, Sprint planning meetings, Sprint reviews/demos, and Sprint retrospectives; roles and responsibilities during Scrum events; and the different layers of planning and appropriate durations when planning an Agile project. You will also have a clear understanding of what completion looks like and what needs to be delivered.

Important Scrum Events

Sprints
The heart of Scrum is a sprint, or a period during which the development team creates a potentially releasable product. Sprints have consistent durations throughout a development effort. A new sprint starts immediately after the conclusion of the previous sprint.

Sprints are performed in sequence starting with a Sprint planning meeting, daily Scrums, a Sprint review, and the Sprint retrospective.

Each sprint has a goal of what is to be built and a flexible plan that will guide building it, the work, and the resultant product Increment.

During the sprint:

• No changes are made that would endanger the sprint goal
• Quality goals do NOT change (while user stories on a sprint can change, the quality of the product should not be impacted)
• Scope may be clarified and re-negotiated between the Product Owner and development team as more is learned

Sprints are limited to one calendar month. When a sprint’s horizon is too long, the definition of what is being built may change, complexity may rise, and risk may increase.

Sprints enable predictability by ensuring inspection and adaptation of progress toward a sprint goal at least every calendar month.

Sprint Planning

The work to be performed in the sprint is planned at the Sprint planning meeting. This plan is created by the collaborative work of the entire Scrum team (consisting of the Product Owner, Scrum Master, and development team). Sprint planning is time-boxed to a maximum of eight hours for a one-month sprint. For shorter sprints, the event is usually shorter.

Sprint planning answers the following:

• What can be delivered in the Increment resulting from the upcoming sprint?
• How will the work needed to deliver the Increment be achieved?

During a Sprint planning meeting, the Scrum Master ensures that the event takes place, that participants understand its purpose, and that the meeting does not exceed the time limit.

The Product Owner discusses the objective that the sprint should achieve, and the Product Backlog items that would, if completed in the sprint, achieve the sprint goal. The sprint goal is an objective that will be met within the sprint through the implementation of the Product Backlog, and it provides guidance to the development team on why it is building the Increment.

The number of items selected from the Product Backlog for the sprint is solely up to the development team. Only the development team can assess what it can accomplish over the upcoming sprint.

The Daily Scrum

The Daily Scrum is a 15-minute time-boxed event for the team, organized by the Scrum Master, and should be held at the same time and place each day to reduce complexity.

The development team uses the Daily Scrum to inspect progress toward the sprint goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the development team will meet the sprint goal. Every day, the development team should understand how it intends to work together as a self-organizing team to accomplish the sprint goal and create the anticipated Increment by the end of the sprint.

The structure of the meeting is as follows:

• What did I do/complete yesterday?
• What will I do/complete today?
• Do I see any impediments that would prevent me or the development team from meeting the sprint goal?

It is very important to share impediments as soon as they arise. Withholding information about an impediment will negatively affect the team’s progress.

Sprint Reviews/Demos

A Sprint review or demo is held at the end of the sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint review, the Scrum team and key stakeholders invited by the Product Owner collaborate about what was done in the sprint.

This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration. For one-month sprints, the review should last four hours at most and be shorter for shorter sprints. It is the Scrum Master’s responsibility to ensure that everyone understands the purpose of the meeting and that it does not exceed the time limit imposed.

During a Sprint review:

• The Product Owner explains what Product Backlog items are “Done” and what has not been “Done”
• The development team discusses what went well during the sprint, what problems it ran into, and how those problems were solved
• The development team demonstrates the work that it has “Done” and answers questions about the Increment
• The Product Owner needs to approve the user stories, and the user stories need to be validated against the acceptance criteria
• The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed)
• The entire group collaborates on what to do next, so that the Sprint review provides valuable input to subsequent Sprint planning meetings
• The Scrum team reviews how the marketplace or potential use of the product might have changed and what is the most valuable thing to do next
• The group reviews the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product

Sprint Retrospectives

The Sprint retrospective is an opportunity for the Scrum team to inspect itself and create a plan for improvements to be enacted during the next sprint.

The Sprint retrospective occurs after the Sprint review and prior to the next Sprint planning meeting. This is at most a three-hour meeting for one-month sprints. For shorter sprints, the event is usually shorter. The Scrum Master ensures that the event takes place, that participants understand its purpose, and that the meeting remains positive and productive. The Scrum Master also encourages the Scrum team to improve its development process and practices within the Scrum process framework.

The purpose of the Sprint retrospective is to:

• Inspect how the last sprint went with regard to people, relationships, process, and tools
• Identify and order the major items that went well and potential improvements
• Create a plan for implementing improvements to the way the Scrum team works

By the end of the Sprint retrospective, the Scrum team should have identified improvements that it will implement in the next sprint. Although improvements may be implemented at any time, the Sprint retrospective provides a formal opportunity to focus on inspection and adaptation.

Scrum Artifacts

The main Scrum artifacts are the Product Backlog, the Sprint Backlog, and the Increment.

Product Backlog

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

A Product Backlog is never complete. The earliest development of it lays out the initially known and best-understood requirements. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. If a product exists, its Product Backlog also exists.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items often include test descriptions that will prove its completeness when “Done.”

Multiple Scrum teams may work together on the same product but only one Product Backlog is used to describe the upcoming work on the product.

When planning your backlog, you are encouraged to use the Planning Onion.

Sprint Backlog

The Sprint Backlog is the set of Product Backlog items selected for the sprint, plus a plan for delivering the product Increment and realizing the sprint goal. The Sprint Backlog is a forecast by the development team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.

The Sprint Backlog makes visible all the work that the development team identifies as necessary to meet the sprint goal. To ensure continuous improvement, it includes at least one high-priority process improvement identified in the previous Sprint retrospective meeting.

The Sprint Backlog has enough detail that changes in progress can be understood in the Daily Scrum. The development team modifies the Sprint Backlog throughout the sprint as it learns more about the work needed to achieve the sprint goal.

When new work is required, the development team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the development team can change its Sprint Backlog during a sprint.

Increment and Definition of Done

The Increment is the sum of all the Product Backlog items completed during a sprint and the value of the Increments of all previous Sprints. To ensure transparency, the team must have a shared understanding of what it means for work to be complete on a product Increment. At the end of a sprint, the new Increment must be “Done,” which means it must have potentially releasable functionality and meet the Scrum team’s current Definition of Done, regardless of whether the Product Owner decides to release it.

It is very important to understand what “Done”_ _means. Although this may vary significantly across Scrum teams, members must have a shared understanding of what it means for work to be complete to ensure transparency. This is the definition of “Done” for the Scrum team and is used to assess when work is complete on the product Increment.

As Scrum teams mature, it is expected that their Definitions of Done will expand to include more stringent criteria for higher quality. New definitions may uncover work to be done in Increments previously considered “Done.”