Sprint Planning

WHAT/WHY: During Sprint Planning a Scrum Team collaboratively plans the work to be done in the Sprint. Sprint Planning is done in order to direct the focus of the Scrum Team towards the Sprint goal.

WHEN: Start of each Sprint.

HOW LONG: At most 8 hours for 1 month sprint. Proportionally shorter based on sprint length.

WHO MUST ATTEND: Scrum Team: Product Owner (PO) + Development Team (Dev Team) + Scrum Master

WHO MAY ATTEND: Subject Matter Experts (SME’s), stakeholders, inter-dependent team members who can help define a valuable Sprint Goal and create a realistic Sprint Plan to achieve it. Some possibilities…

• UI / UX Designers (if they are not already included in the Dev Team)
• DBA (if they are not already included in the Dev Team)
• DevOps / Release Management / Ops (if they are not already included in the Dev Team)
• SM + appropriate Development Team representatives from inter-dependent teams
• Infosec (if they are not already included in the Dev Team)
• Appropriate Business Stakeholders

HOW: The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team.

WHAT HAPPENS BEFORE:

• Team has refined enough “actionable” / “ready” items to keep them busy for at least 1 sprint, ideally 2-3 Sprints
• Each “ready” item meets the following criteria – every member of the Dev Team has a shared understanding with the PO on…
1. What is the business problem we are trying to solve? What is the intent of this PBI?
2. Who (persona) are we trying to solve this problem for?
3. Why is this problem important for us to solve?
4. When does this problem pop-up? Any pre-requisites / triggers before the persona needs to solve this problem?
5. What is the desired outcome – what “acceptance tests” will the PO execute to verify that we met the intent?
6. Once this is deployed to production, what indicators / metrics will we use to measure that this item is achieving the desired outcome
7. Any additional information that the Dev Team might need for estimation, ex. wire-frames, NFR’s, etc.
8. Dev team has got all their clarifying questions answered and has estimated the PBI in relative story points
9. Dev team feels confident that they understand the intent of the item well-enough to decompose it into 1 day tasks in Sprint Planning
• PO has identified a high-level business problem they would like the Dev Team to solve by the end of the Sprint
• PO has identified a starter list of “ready” PBI’s that (s)he feels can help achieve the chosen high-level business problem

WHAT HAPPENS DURING:

1. INTRODUCTION:

   Scrum Master / Facilitator explains the intent – before we end this meeting, we will all align behind…

   • 1 Scrum Team DOD
   • 1 Scrum Team Working Agreement
   • 1 Scrum Team Sprint Goal
   • 1 Sprint Backlog
   • 1 Sprint Plan
   • Enough 1-day tasks to keep us busy for a few business days
   • Team Availability for all of us in hours – excluding holiday’s, vacation, training, any other commitments we need to honor
2. FOUNDATIONS:
   • Team captures their upcoming capacity in hours available to work during this sprint – holiday, vacation, training, company events
   • Team captures historical velocity
   • Team decides what velocity to use for planning purposes for this sprint based on past velocity and upcoming
   • Based on the the last Sprint Retrospective / Sprint Review team makes necessary updates to Working agreement and DOD.
3. INTENT (WHY) – WHAT ARE WE DOING, WHY, FOR WHOM?
   • PO explains a high-level business problem (s)he would like the team to help solve
   • PO lists the “ready” backlog items that (s)he feels can help us achieve
   • Team asks clarifying questions
   • PO may leave after all clarifying questions have been answered provided they are available to rejoin the team at short notice as needed
4. PLANNING (HOW) – HOW WILL WE DO IT?
   • Dev Team starts creating a plan to achieve the business outcome proposed by the PO
   • Sprint goal starts emerging
   • Dev Team considers capacity and dependencies to define the Sprint Backlog
   • Dev Team starts creating a high level Sprint Plan on how to complete all items in the Sprint Backlog
   • Dev Team may go back to the PO with counter-proposals on adding / modifying backlog items based on their discussion
   • Dev Team decomposes enough PBI’s into 1 day tasks to keep everyone busy for a few business days
   • Dev Team members volunteer to pick up tasks
   • Every PBI should move from “In Progress” to “Done” and be ready for PO Acceptance within 3-4 business days. This means more than 1 Developer must work on each PBI
   • There should not be less than 2 Developers working on any PBI. Preferably more so we “swarm” and start finishing items instead of having a high number of items partially completed and “in progress”
   • Dev Team identifies a list of impediment, risks.
5. ALIGNMENT :
   • PO rejoins the team
   • PO inspects the plan, asks clarifying questions if needed
   • Appropriate changes are made to the Sprint Plan based on PO feedback
   • Entire Scrum Team crafts one single Sprint Goal that acts as a True North for the entire Sprint
   • Entire Scrum Team expresses confidence level through a “Fist to Five”
   • Appropriate changes are made until every single Scrum Team members is at a 3 or higher
   • Entire team participates in a Quick Retro on Sprint Planning
   • Sprint Planning is over – adjourn

WHAT HAPPENS AFTER:

• Dev Team updates any ALM tools with Sprint Backlog, Tasks, etc.,
• Sprint Plan is captured
• Scrum Master starts removing any impediments
• Dev Team starts doing the work of the Sprint and updating tools per working agreement to visualize Sprint Burn-Down Chart
• Dev Team continuously adapts Sprint Forecast/Backlog + Plan and updates tasks in a tracking tool.
• Dev Team engages PO for clarifications as needed.

Daily Scrum

WHAT / WHY: The Daily Scrum is a short daily meeting to inspect progress towards the Sprint Goal. It allows the Development Team to optimize collaboration and performance.

WHEN: The Daily Scrum is held every day of the Sprint at the same time and place to reduce complexity.

HOW LONG: The Daily Scrum is a 15-minute time-boxed event that’s held every day at the same place and time of the Sprint.

WHO MUST ATTEND: The Development Team

WHO MAY ATTEND: The Scrum Master and the Product Owner

HOW: The Daily Scrum is where the Development Team plans work for the next 24 hours.

WHAT HAPPENS BEFORE:

• Product Backlog,
• Sprint Planning
• Sprint Backlog

WHAT HAPPENS DURING: The Daily Scrum answers these questions:

• 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?

WHAT HAPPENS AFTER:

• Sprint (Development Team begins the work).
• 16th Minute (Development Team discusses issues and solutions that still need to be addressed as needed).

Sprint Review

WHAT / WHY: This is a collaborative session with the Scrum Team and Stakeholders to inspect the Increment, gather feedback, and determine what can be done to optimize the value of the Increment. This optimizes the value of the Increment and helps determine what Product Backlog Items are priority for the next Sprints.

WHEN: The Sprint Review is held at the end of a Sprint.

HOW LONG: It’s a time-boxed event of 4 hours maximum, proportionally shorter based on Sprint length.

WHO MUST ATTEND: Scrum Team: Product Owner + Development Team (Dev Team) + Scrum Master

WHO MAY ATTEND: Stakeholders

HOW: During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint.

WHAT HAPPENS BEFORE:

• These events happen: Product Backlog, Sprint Planning, Sprint Backlog, Daily Scrum
• “Done” Increment is created.

WHAT HAPPENS DURING:

• The Dev Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved.
• The Dev Team demonstrates the work that it has “Done” and answers questions about the Increment.
• The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning.
• The Product Backlog is updated upon the new insights.

WHAT HAPPENS AFTER:

• The Sprint Retrospective.
• A revised Product Backlog that defines the probable PBIs for the next Sprint is created.

Sprint Retrospective

WHAT / WHY: During the Sprint Retrospective, the Scrum Team inspects itself and its processes in order to improve said processes. This increases the efficiency of the future Sprints.

WHEN: The Sprint Retrospective is the last thing done in a Sprint. This event follows the Sprint Review and precedes Sprint Planning for the next Sprint.

HOW LONG: 3 hours maximum for a 1 month Sprint with shorter retrospectives for shorter Sprints.

WHO MUST ATTEND: Scrum Team: Product Owner + Development Team + Scrum Master

WHO SHOULD NEVER ATTEND: Stakeholders, managers, anyone who is not part of the Scrum Team

HOW: During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”, if appropriate and not in conflict with product or organizational standards.

WHAT HAPPENS BEFORE: Sprint Review

WHAT HAPPENS DURING:

• The Scrum Master encourages the Scrum Team to improve its development process and practices within the Scrum framework to make the next Sprint more effective and enjoyable.
• The Scrum Team inspects how the last Sprint went with regards to people, relationships, process, and tools and identifies and orders the major items that went well and potential improvements.
• The Scrum Team creates a plan for implementing improvements to the way the Scrum Team does its work through methods such as improving work processes or adapting the “Definition of Done” if appropriate and not in conflict with product or organizational standards.

WHAT HAPPENS AFTER: The next Sprint begins and improvements are implemented.

Backlog Refinement

WHAT / WHY: Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This process increases effectivity of Sprint Planning by familiarizing people with Product Backlog Items and creates enough ready and actionable items to work on during the next Sprint.

WHEN: The Scrum Team decides how and when refinement is done.

HOW LONG: Usually consumes no more than 10% of Development Team Capacity; It is an ongoing process.

WHO MUST ATTEND: Product Owner + Development Team

WHO MAY ATTEND: Scrum Master

HOW: Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog.

WHAT HAPPENS BEFORE: The Scrum Team decides how and when refinement is done.

WHAT HAPPENS DURING:

• Product Backlog Items (PBIs) are reviewed and revised.
• Details and estimates are added to Product Backlog Items and the order of Product Backlog Items is determined.
• However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

WHAT HAPPENS AFTER: You will have the most updated Product Backlog for the current Sprint.

Product Backlog

WHAT / WHY: The Product Backlog is an ordered list of everything that is known to be needed in the product. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful.

WHEN: The Product Backlog exists before you create your Product.

HOW LONG: As long as you have Product, the Product Backlog exist. A Product Backlog is never complete. The earliest development of it lays out the initially known and best-understood requirements.

WHO MUST ATTEND: Product Owner + Development Team

WHO MAY ATTEND: Scrum Master

HOW: The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.

WHAT HAPPENS BEFORE: The concept of the Product

WHAT HAPPENS DURING:

• As a product is used and gains value, and the marketplace provides feedback,
• the Product Backlog becomes a larger and more exhaustive list
• Requirements never stop changing
• Product Backlog is a living artifact.

WHAT HAPPENS AFTER: Sprint Planning

Sprint Backlog

WHAT / WHY: 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 makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal.

WHEN: The Sprint Backlog occurs throughout the  Sprint.

HOW LONG: The Sprint Backlog exists as long as there is a Sprint.

WHO MUST ATTEND: Development Team

HOW: The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team.

WHAT HAPPENS BEFORE: Sprint Planning

WHAT HAPPENS DURING:

• The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum.
• it includes at least one high priority process improvement identified in the previous Retrospective meeting.
• The Development Team modifies the Sprint Backlog throughout the Sprint
• the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

WHAT HAPPENS AFTER: The Daily Scrum

Increment

WHAT / WHY: An increment is the composed of all Product Backlog items completed during a Sprint and all the increments of the previous Sprints. At the end of a Sprint, the new increment must be “Done” meaning that it must meet the Scrum Team’s “Definition of Done” and be in useable and releasable condition. It is a body of inspectable “done” work that supports empiricism and is a step towards a vision or goal. Even if a Product Owner chooses not to release the increment, it must be in useable condition.

WHEN: The Increment is created and maintained during the Sprint(s).

HOW LONG: At the end of a Sprint, the new increment must be “Done,”which means it must be in useable condition and meet the Scrum Team’s definition of “Done”.

WHO: The Product Owner. The Development Team.

HOW: The Increment is the sum of all Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.

WHAT HAPPENS BEFORE:

• Product Backlog
• Product Backlog Refinement
• Sprint Planning
  • Create Sprint Goal
  • Create Definition of “Done”
  • Sprint Forecasting
  • Sprint Backlog
• Daily Scrum
• Development Work

WHAT HAPPENS DURING: The Increment is the sum of all Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.

WHAT HAPPENS AFTER: At the end of a Sprint, the new increment must be “Done,”which means it must be in useable condition and meet the Scrum Team’s definition of “Done”.

Scrum Team

WHAT / WHY: The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.

Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.

The team model in Scrum is designed to optimize flexibility, creativity, and productivity. The Scrum Team has proven itself to be increasingly effective for all the earlier stated uses, and any complex work.

Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.

WHO: Product Owner (PO) + Development Team (Dev Team) + Scrum Master (SM)

HOW: Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity. The Scrum Team has proven itself to be increasingly effective for all the earlier stated uses, and any complex work.

Scrum Master

WHAT / WHY: The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

ROLE: The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

The Scrum Master Service to the Product Owner:

• Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible.
• Finding techniques for effective Product Backlog management.
• Helping the Scrum Team understand the need for clear and concise Product Backlog items.
• Understanding product planning in an empirical environment.
• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value.
• Understanding and practicing agility.
• Facilitating Scrum events as requested or needed.

Scrum Master Service to the Development Team:

• Coaching the Development Team in self-organization and cross-functionality.
• Helping the Development Team to create high-value products.
• Removing impediments to the Development Team’s progress.
• Facilitating Scrum events as requested or needed.
• Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

Scrum Master Service to the Organization:

• Leading and coaching the organization in its Scrum adoption.
• Planning Scrum implementations within the organization.
• Helping employees and stakeholders understand and enact Scrum and empirical product development.
• Causing change that increases the productivity of the Scrum Team.
• Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

Product Owner

WHAT / WHY: The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one can force the Development Team to work from a different set of requirements.

ROLE: The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

• Clearly expressing Product Backlog items.
• Ordering the items in the Product Backlog to best achieve goals and missions.
• Optimizing the value of the work the Development Team performs.
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed.
• The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

Development Team

WHAT / WHY: The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. A “Done” increment is required at the Sprint Review. Only members of the Development Team create the Increment.

Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.

ROLE: The Development Team creates the “Done” increment of a product.

Development Teams have the following characteristics:

• They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.
• Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment.
• Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person.
• Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis.
• Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

Development Teams Size:

• The Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint.
• Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination.
• Large Development Teams generate too much complexity for an empirical process to be useful.
• The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.

About

Our Purpose

The “Scrum Events Playbook”, created by the Three Amigos Scrum Team, is an educational, interactive tool designed to improve understanding, implementation and facilitation of the Scrum framework for those who are inexperienced with Scrum by providing visual details on Scrum events and activities.

We hope this guide will serve to improve efficiency and strengthen Scrum Teams while facilitating a deeper understanding of Scrum in those interested in the concept or implementation of Scrum. With this we hope to spread our passion for Scrum to others.

Tips

• Click on sections of the Scrum Framework below to see detailed information beneath the image.
• On Computers, hover over the sections of the Scrum Framework below to see a brief overview of the content in the tooltip.
• On Mobile devices, loading might take a bit longer.