89 Scrum Events

Product Backlog

Sprint Backlog

SprintRetrospective MeetingSprint Review MeetingDaily ScrumSprint Planning MeetingBacklog Refinement Meeting

User login

User login

determine requirements for password policy

page layout (design)

get latest JBoss running

SSL enable

Selected Product Increment

choose persistence strategy (Hibernate?)

write code (using test-driven


exploratory testing

Reset lost password

Account lockout

SSL enable

analyze example config file

get official

certificate from I.T.install certificate

update deploy target in build.xml

exploratory testing (3 browsers)

update installation document

LDAP integration

Reset lost password

agree on best algorithm for randomizing passwords

decide where to put the link

code (using test- driven


Register a new login

Edit registration

Admin reporting

Account lockout af ter three


add screenshot and text to user manual

code (using test-driven development)

exploratory testing

update migration tool to include new row for locked account

manual test (try to break in with policy installed)


update documents

Figure 3: Scrum flow.

Sprint Planning

At the beginning of each Sprint, the Product Owner and team plan which Product Backlog Items they will attempt to convert to working product during the Sprint. The Product Owner is responsible for declaring which items are the most important to the business. The Development Team is responsible for selecting the amount of work they feel they can implement without accruing technical debt. The team “pulls” work from the Product Backlog to the Sprint Backlog.

When teams are given complex work that has inherent uncertainty, they must work together to intuitively gauge how much work to pull into a Sprint, while learning from previous Sprints. Planning their hourly capacity and comparing their estimates to actuals makes the team pretend to be precise and reduces ownership. Unless the work is truly predictable, they should discard such practices within the first few Sprints or avoid them altogether.

Until a team has learned how to complete a potentially releasable product increment each Sprint, it should reduce the amount of functionality it plans. Failure to change old habits leads to technical debt and eventual design death, as shown in Figure 14.

If the top of the Product Backlog has not been refined, a portion of the event might be spent doing this.

Toward the end of the Sprint Planning Event, the team determines how it will accomplish the work. For example, they may break the selected items into an initial list of Sprint Tasks.

The maximum allotted time (a.k.a. timebox) for planning a 30-day Sprint is eight hours, reduced proportionally for a shorter Sprint.

Figure 4: Sprint Planning outcome is selected Product Backlog Items (PBIs) and subordinate Sprint Tasks.

Daily Scrum and Sprint Execution

Every day at the same time and place, the Scrum Development Team members spend a total of 15 minutes inspecting their progress toward the Sprint goal and creating a plan for the day. Team members may share with each other what they did the previous day to help meet the Sprint goal, what they’ll do today, and what impediments they face.

Standing up at the Daily Scrum will help keep it short. Topics that require additional attention may be discussed by whoever is interested after every team member has spoken.

The team may find it useful to maintain a current Sprint Task List and a Sprint Burndown Chart. During Sprint execution, it is common to discover additional tasks necessary to achieve the Sprint goals.

Impediments caused by issues beyond the team’s control are considered organizational impediments.

The Daily Scrum is intended to disrupt old habits of working separately. Members should remain vigilant for signs of the old approach. For example, looking only at the Scrum Master when speaking is one symptom that the team hasn’t learned to operate as a self-organizing entity.

Sprint Review

At the end of the Sprint, the Scrum Team holds Sprint Review to inspect and adapt the product as it emerges. They demonstrate a working product increment to everyone who is interested, particularly customers and end users, and get their feedback.

The team reviews the items selected during Sprint Planning and explains which items are considered done. For example, a software item that is merely “code complete” is considered not done because untested software isn’t shippable. Incomplete items are returned to the Product Backlog and ranked according to the Product Owner’s revised priorities as candidates for future Sprints.

The Scrum Master may help the Product Owner and stakeholders convert their feedback to new Product Backlog Items for prioritization by the Product Owner. Often, new scope discovery outpaces the team’s rate of development. If the Product Owner feels that the newly discovered scope is more important than the original expectations, new scope displaces old scope in the Product Backlog. Some items will never be done.

External stakeholders and end users should participate. New products, particularly software products, are hard to visualize in a vacuum. Many customers need to be able to react to a piece of functioning software to discover what they will actually want. Iterative development, a value- driven approach, allows the creation of products that couldn’t have been specified up front in a plan-driven approach.

Sprint Retrospective

Each Sprint ends with a retrospective. The team reflects on its own process. They inspect their behavior and take action to adapt it for future Sprints.

Dedicated Scrum Masters will find alternatives to the stale, fearful meetings everyone has come to expect. An in-depth retrospective requires an environment of psychological safety not found in most organizations. Without safety, the retrospective discussion will either avoid the uncomfortable issues or deteriorate into blaming and hostility.

A common impediment to full transparency on the team is the presence of people who conduct performance appraisals.

Another impediment to an insightful retrospective is the human tendency to jump to conclusions and propose actions too quickly. Agile Retrospectives, the most popular book on this topic, describes a series of steps to slow this process down: Set the stage, gather data, generate insights, decide what to do, close the retrospective.1 Another guide recommended for Scrum Masters, The Art of Focused Conversations, breaks the process into similar steps: Objective, reflective, interpretive, and decisional (ORID).2

A third impediment to psychological safety is geographic distribution. Geographically dispersed teams usually do not collaborate as well as those in team rooms.

Retrospectives often expose organizational impediments. Once a team has resolved the impediments within its immediate influence, the Scrum Master should work to expand that influence, chipping away at the organizational impediments.

Scrum Masters should use a variety of techniques to facilitate retrospectives, including silent writing, timelines, and satisfaction histograms. In all cases, the goals are to gain a common understanding of multiple perspectives and to develop actions that will take the team and organization to the next level.

any allergy records exist.” While the engineers anticipated significant technical challenges in parsing the internal aspects of the allergy records, the presence or absence of any allergy was the most important thing the doctors needed to know. Collaboration between business people and technical people to split this epic yielded a story representing 80% of the business value for 20% of the effort of the original epic.

Since most customers don’t use most features of most products, it’s wise to split epics to deliver the most valuable stories first. While delivering lower-value features later is likely to involve some rework, rework is better than no work.

This activity has also been called “Backlog Grooming.”

Cut/ pasteplainCut/textpaste rich textCut/paste rich text and graphicsdatabase schema

Figure 5: During Backlog Refinement, large PBIs (often called “epics”) near the top of the Product Backlog are split into thin vertical feature slices (“stories”), not horizontal implementation phases.


Icon for the Creative Commons Attribution 4.0 International License

Project Management Basics Copyright © by Sharon Blanchard is licensed under a Creative Commons Attribution 4.0 International License, except where otherwise noted.