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
development)
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
development)
Register a new login
Edit registration
Admin reporting
Account lockout af ter three
attempts
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)
User-managed
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.
