image/svg+xml Scrum Framework © Scrum.org SprintReview Increment BacklogRefinement SprintBacklog DevTeam ProductOwner ScrumMaster ProductBacklog SprintPlanning SprintRetrospective DailyScrum Sprint 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 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 Product Backlog is an ordered list of everything that is known to be needed in the product. Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. An increment is the sum of all the Product Backlog items completed during a Sprint that can be inspected. The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide by helping everyone understand Scrum theory, practices, rules, and values. 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 Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. Sprint Planning is a time-boxed event at the beginning of a Sprint where the Scrum Team plans the work to be performed. 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 Daily Scrum is a 15-minute time-boxed event for the Development Team that is held every day of the Sprint. The heart of Scrum, a Sprint is a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.

WHAT / WHY: The heart of the Scrum is a Sprint, a time-box of 1 month or less during which a “Done”, useable, and potentially releasable product increment is created. A Sprint acts as a container of risk so that at most what is lost is 1 month’s worth of work and time to market.

WHEN: Sprints have consistent durations and a new Sprint starts immediately after the previous Sprint.

HOW LONG: 30 days or less.

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

WHO MAY ATTEND: Subject Matter Experts (SME’s) + Shared Team Members

WHAT HAPPENS BEFORE: Scrum Team is defined and Product Backlog is created.

WHAT HAPPENS DURING:

  • Sprint Backlog, Sprint Goal and Definition of Done is created.
  • Scrum events such as the Product Backlog Refinement, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective and the Development Team’s work takes place.
  • A working Increment (Minimum Viable Product) that meets the “Definition of Done” is completed by the end of the Sprint. No changes are made that would endanger the Sprint Goal.
  • Scope may be clarified and renegotiated between Product Owner and the Development Team as more is learned.

WHAT HAPPENS AFTER: The next Sprint Begins.

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

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.

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)

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:

  • Product Backlog Items (PBI’s) are rank-ordered by value, cost, risk.
  • Product Backlog has sufficient “ready” & actionable PBIs for effective Sprint Planning.

WHAT HAPPENS DURING:

  • Review team capacity and define/refine working agreement and Definition Of Done.
  • PO explains what/why and the Dev Team creates plan/how.
  • The Development Team determines their Sprint Goals and what PBIs they will get done in the sprint.
  • Iterate & Align on Sprint Goal + Forecast/Backlog + Plan.
  • Enter initial tasks into a tracking tool (JIRA, Rally, Trello, Kanban Board).
  • Capture risks/impediments.

WHAT HAPPENS AFTER:

  • Dev Team continuously adapts Sprint Forecast/Backlog + Plan and updates tasks in a tracking tool.
  • Dev Team engages PO for clarifications and they work on scope as needed.

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

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.

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.

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.

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.

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.

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).

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”.

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.

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.

Webpage created by Three Amigos Scrum Team

Trophenia Kineard
Professional Scrum Master
PSM I

Ceceille Palmer
Professional Scrum Master
PSM I

Jasmine Tsai
Professional Scrum Developer
PSM I