Sprint Planning Meeting

 

At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to negotiate 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. If the top of the Product Backlog has not been refined, a portion of the Planning meeting might be spent doing this. Toward the end of the Sprint Planning Meeting, 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.

 

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 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 reported. 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 Meeting

 

At the end of the Sprint, the Scrum Team holds a Sprint Review Meeting to demonstrate a working product increment to everyone who is interested, particularly outside stakeholders. The meeting should feature a live demonstration, not a report. The Product Owner reviews the items selected during the Sprint Planning Meeting 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 helps 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. The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end-users) to attend. It is the opportunity to inspect and adapt the product as it emerges. 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 upfront in a plan-driven approach.

 

Sprint Retrospective Meeting

 

Each Sprint ends with a retrospective. At this meeting, 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. 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.

 

Backlog Refinement Meeting

 

Most Product Backlog Items (PBIs) initially need refinement because they are too large and poorly understood. While Backlog Refinement is not a required event, it is a required activity. Most Scrum Teams find it useful to take a short time out of every Sprint for this activity. They get together to prepare the Product Backlog for upcoming Sprint Planning Meetings.

 

In the Backlog Refinement Meeting, large vague items are split and clarified, considering both business and technical concerns. Sometimes a subset of the team, in conjunction with the Product Owner and other stakeholders, will compose and split Product Backlog Items before involving the entire team.

 

While refining items, the team may estimate the amount of effort they would expend to complete items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

 

A skilled Scrum Master can help the team identify thin vertical slices of work that still have business value while promoting a rigorous definition of “done” that includes proper testing and refactoring. It is common to write Product Backlog Items in User Story form. In this approach, oversized PBIs are called epics. Traditional development breaks feature into horizontal tasks (resembling waterfall phases) that cannot be prioritized independently and lack business value from the customer’s perspective. This habit is hard to break.

 

Agility requires learning to split large epics into user stories representing very small product features. For example, in a medical records application the epic “display the entire contents of a patient’s allergy records to a doctor” yielded the story “display whether or not 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,” “Backlog Maintenance,” or “Story Time.”