The Sprint (up to 1 month max)
A time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.
During the Sprint: • No changes are made that would endanger the Sprint Goal; • Quality goals do not decrease; and, • Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change.
Sprint Planning (max 4h for 2-week sprints)
Answers two questions: • What can be done this Sprint? • How will the chosen work get done?
The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint. The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. 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 Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.
Work may be of varying size, or estimated effort. However, enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less. The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.
The Product Owner can help to clarify the selected Product Backlog items and make trade-offs. If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner.
By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.
The Daily Scrum is a 15-minute time-boxed event held every day at the same time for the Development Team.
Development Team plans work for the next 24 hours and inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work.
The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. :• What did I do yesterday that helped the Development Team meet the Sprint Goal? • What will I do today to help the Development Team meet the Sprint Goal? • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.
The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum.
This is a key inspect and adapt meeting.
What: informal meeting collaboration & feedback what was done in spring, with all including PO & SH When: at the end of the Sprint Why: to inspect the Increment and adapt the Product Backlog if needed. How long: up to 2h
Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.
ensures that the event takes place and that attendees understand its purpose. teaches everyone involved to keep it within the timebox.
What is includes:
• Attendees include the Scrum Team and key stakeholders invited by the Product Owner; • The Product Owner explains what Product Backlog items have been “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 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; • Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and, • Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.
The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.
Sprint Retrospective (needs to be positive and productive)
Goal: to inspect itself (good and less good: people, relationships, process, tools) and plan improvements for next sprints (enjoyable & efficient), Adapt Definition of Done When: after Sprint Review How Long: up to 1.5h
Improvements for next sprints: adaptation of inspection from Team
Who: PO and Team What: review items in PB to insure it contains prioritized appropriate items, and top of Backlog ready for delivery. When: regular basis and may be an officially scheduled meeting or an ongoing activity. The Scrum Team decides how and when refinement is done. Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion. How long: Refinement usually consumes no more than 10% of the capacity of the Development Team.
What it included: removing user stories that no longer appear relevant creating new user stories in response to newly discovered needs re-assessing the relative priority of stories assigning estimates to stories which have yet to receive one correcting estimates in light of newly discovered information splitting user stories which are high priority but too coarse grained to fit in an upcoming iteration
Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning.The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.