The Complete Guide to Practical Agile Software Development

As a leading software development company we pride ourselves on consistently delivering exceptional results for our clients. One of the ways we deliver exceptional results is by using Agile methodology in our development process. Agile, scrum, iterative are term soften used in the industry to describe structured development of software involving quick iterations and built in feedback mechanisms from stakeholders.

But, the general agile framework is often too loose for most firms to follow. Over more than a decade of software development we developed the Practical Agile methodology for software development and use it the core of our software development process.

All teams are part skill and part process. We have found that over the years, larger teams and long term projects will fall apart without process. Here is ours.

Section 1 : Guidelines - Splitting User Stories

Content:

• Splitting User Stories
• The INVEST model
• Vertical vs Horizontal Splitting
• Splitting User Stories: Example
• Breakdown by Workflow: Example

Splitting User Stories

Sometimes a user story is too big to fit into a Sprint. The simplest approach to splitting is to look for a literal or implied conjunction “and” or “or” in the text of the story and then create two or more new stories from the parts around the conjunction. For example: “As a user I can do one thing and another thing so that I’m happy.” That can be split into “As a user I can do one thing so that I’m happy” and another story “As a user I can do another thing so that I’m happy.”

Some ways of splitting a story include:

• Split by process step – every step is a new user story
• Split by I/O channel – each I/O channel becomes a separate story
• Split by user options – the options become the user stories
• Split by role/persona – each role/persona becomes a separate story
• Split by data range – every significant range is a new user story (e.g. 0, 1-9, 10-99 or last year, this year, next year).
• Split by CRUD action – create, read, update, delete (only applicable if each action has business logic and they are asymmetric).
• Breaking down by business rules
• Breaking down by happy / unhappy flow
• Breaking down by input options / platform
• Breaking down by data types or parameters
• Breaking down by operations (CRUD)
• Breaking down by test scenarios / test case
• Breaking down by roles
• Breaking down by ‘optimize now’ vs ‘optimize later’
• Breaking down by browser compatibility

The INVEST model is a good way to test whether user stories are well-written.

• I – Independent
• N – Negotiable
• V – Valuable
• E – Estimable
• S – Small
• T – Testable

Independent– Each user story must be independent of each other. This prevents any overlap between the items; moreover, it allows the team to implement them in any order.

Negotiable– The details of the work must be negotiable, both among the stakeholders and the team. Specific requirements and design decisions will be fleshed out during development. Many agile practitioners recommended writing user stories on a note card — this is intentional so that a limited amount of detail can be prescribed.

Valuable– Each user story must add business value to the product, the customer and/or the users’ experience.

Estimable¬– A good user story can be understood well-enough by the team that they can estimate it — not accurately — but at a high-level they perceive that it has size. It is helpful to understand the relative effort as compared to other user stories.

Small– A user story is not small if the team cannot get it done within a single Sprint. As large user stories are split into smaller items, greater clarity about the size and implementation is achieved, which improves the likelihood that the team will get it done within a Sprint.

Testable– Each user story should be testable; this is a common characteristic of well written requirements. If the team cannot determine how the user story may be tested, it is an indication that either desired functionality or the desired business value is not clear enough.

Independent (I)

1. User Stories should be free of dependencies on other user stories.
2. User Stories should be self-contained.
3. User Stories should be completed and released in any order.
4. User Stories should be combined or split in different ways when dependencies occur.

Negotiable (N)

1. User Stories should not be contractual obligations as they are negotiable.
2. User Stories should be a collaborative negotiation between customers, developers and testers.

Valuable (V)

1. User Stories should be of value to the user or owner of the software.
2. User Stories should not be only of value to developers.
3. User Stories should clearly define the benefit to customers/users to assist in prioritization.
4. User Stories should be written by customers to ensure it is valuable to customers/users.

Estimatable (E)

1. User Stories should be estimated in terms of story points.
2. User Stories should be clearly understood before it is estimated by development teams.
3. User Stories should contain enough detail before it is estimated by development teams.
4. User Stories may not be estimatable when development teams lack domain knowledge.
5. User Stories may not be estimatable when development teams lack technical knowledge.
6. User Stories may not be estimatable when the user story is too big.

Small (S)

1. User Stories should be as small as possible while still providing user value.
2. User Stories should be able to fit into one iteration.
3. User Stories that are too big will be difficult to understand and estimate.

Testable (T)

1. User Stories should be verified by tests to prove they are implemented correctly.
2. User Stories should contain the story acceptance criteria to guide testing.
3. User Stories should be easily unit tested. (Technical Implementation)
4. User Stories should be easily acceptance tested. (Behavioural)
5. User Stories should be tested in an automated manner where possible.

Definition of Done (DoD)

There are numerous criteria a team can use to define their Definition of Done. This ensures that teams deliver features that are completed in terms of functionality and quality. Definition of Done is an auditable checklist. The following is a set of possible criteria and activities for a DoD:

1. Unit Tests Passed
2. Acceptance Criteria Met
3. Code Reviewed
4. Functional Tests Passed
5. Non-Functional Requirements Met
6. Product Owner Accepts User Story

User Story Example

The following is an example of a user story.

Here is another example:

Vertical vs Horizontal Splitting

There are two common ways to split user stories: vertically or horizontally. Horizontal breakdown of user stories splits the item at an architectural component level. Example: front end UI, databases or backend services. Whereas, a vertical slice results in working, demonstrable, software which adds business value. Therefore, it is recommended to slice user stories vertically so as to reduce dependencies and improve the team’s ability to deliver a potentially shippable product increment in each sprint.

Splitting User Stories: Example

As a customer I can pay for my order so that I receive the products

If the above user story was to be split in a vertical manner, it might be broken down into the various ways a customer can complete a payment. As follows…

As a customer I can make a credit card payment for my order so that I collect reward points on my credit card.

And/or

As a customer I can make a PayPal payment for my order so that I can securely complete my purchase without sharing credit card details with another retailer.

The key point to note in the vertically sliced user stories above is that each story passes the INVEST tests mentioned earlier and therefore a Product Owner can prioritize these user stories based on customer needs. However, if a horizontal approach was used to split the user story (i.e. split by architectural layers and components) then the implementation of such requirements would result in working functionality only when all horizontal components are eventually integrated.

Breakdown by Workflow: Example

Another approach that is commonly used to breakdown user stories is focused on the individual steps a user may take in order to achieve their end goal — that is, a user story which describes a long narrative or “user flow” through a system may be sliced into steps which represent portions of the user’s flow. Continuing from the example above of a customer making a purchase online, the user story can be broken down into the following:

As a customer I can review the items being purchased for my order so that I can be confident I’m paying for the correct items.

As a customer I can provide my banking information for my order so that I can receive the products I ordered.

As a customer I can receive a confirmation ID for my purchase so that I can keep track and keep a record of my purchase.

Section 2 : Product Backlog Refinement

Content:

• Product Backlog Refinement
• Goals
• Artifacts
• Process of Refinement

Product Backlog Refinement

Goals

• Get the Product Backlog Ready for the next Sprint Planning meeting
• Get 6 months of Product Backlog Items estimated so the Product Owner (PO) can forecast well

Who: whole Scrum team

The whole Scrum team is invited. The Product Owner is present—he is responsible for the Product Backlog. The Scrum Master is present—he is a good facilitator and can help the team succeed. The Development Team members are present—they are responsible for estimating the size of the Product Backlog Items (PBIs), and they want to be familiar with the PBIs before Sprint Planning.

When & where

• Same time and place, every week: so everyone knows and everyone can participate
• 2-hour time box

Artifacts

• Input: The input to the workshop is the Product Backlog in its current state.
• Output: The output is a Product Backlog that is more Ready

Process of Refinement

To conduct the workshop, follow these steps:

In 30-minute cycles,

• The PO presents the next PBIs in the order of priority that aren’t Ready to the team. (up to 5 minutes)
• For each PBI in the order of priority, follow the steps outlined below

*PO: Discuss the PBI (what and the why)

Section 3 : Sprint Review

Content:

SPRINT REVIEW

• SPRINT REVIEW OVERVIEW
• SPRINT REVIEW TIMING
• SPRINT REVIEW PARTICIPANTS
• SPRINT REVIEW PREWORK
• SPRINT REVIEW APPROACH

1. Overview (Summarize)
2. Demonstrate
3. Discuss
4. Adapt

SPRINT REVIEW

Near the end of the sprint, the team conducts two important inspect and adapt activities:

• The sprint review
• The sprint retrospective.

SPRINT REVIEW OVERVIEW

The sprint review is the time when the Scrum team invites its stakeholders to give feedback on the product itself. Recall that during spring planning, the team planned the work. During spring execution the team did the work. And now, in the sprint review, the team inspects the result of the work—the potentially shippable product increment.

SPRINT REVIEW TIMING

The sprint review occurs near the end of the sprint, just after sprint execution and just before the sprint retrospective

SPRINT REVIEW PARTICIPANTS

The sprint review is an excellent opportunity for the Scrum team to get feedback from people who typically are not available on a daily basis during sprint execution. For these individuals, the sprint review is their first opportunity to see and discuss the work that was produced during the sprint. The invitation list for the sprint review, therefore, should include all interested parties.

The entire Scrum team (development team, ScrumMaster, and product owner) should attend. Other potential attendees include internal stakeholders (e.g., internal users or subject matter experts) other internal teams (e.g., marketing or support), and even external stakeholders (e.g., external customers or partners).

SPRINT REVIEW PREWORK

Although sprint reviews are informal by design, the teams should do some minimal prep work.

• Invitations
  The team must determine who to invite. The list is likely to vary somewhat from sprint to sprint depending on the work accomplished during the sprint.
• Scheduling
  The sprint review should be scheduled around the availability of a few must-have stakeholders. Ideally, this day and time could be fixed for all of the sprints, so that it occurs at a regular cadence. Remember that the sprint review should be time-boxed, and typically takes somewhere between 2 and 4 hours depending on sprint length.
• Confirmation
  The team can only present completed work at the review, so sometime before the sprint review, the team must ensure that the work is indeed done.
• Demo Prep
  This is to show case the work done during the sprint. Since the work is already done by the time this meeting is happening, not much preparation is required unless product owner/product manager needs a different method of Demo (such as power point of screens etc )
• Role Determination
  The team needs to decide who on the Scrum team is going to facilitate the review (often, but not always, the Scrum-Master) and who is going to demonstrate the completed work.

SPRINT REVIEW APPROACH

The inputs to the sprint review are the sprint goal, sprint backlog, and the potentially shippable product increment that the team actually produced during the sprint. The outputs are a groomed product backlog and an updated release plan. A common approach to conducting the sprint review is as follows: Overview (Summarize), Demonstrate, Discuss, and Adapt.

Overview (Summarize)

The sprint review kicks off with a Scrum team member (often the product owner) presenting the sprint goal, the product backlog items associated with that goal (often the sprint backlog), and an overview of the product increment that the team achieved during the sprint. This information provides a summary or synopsis of how the sprint results compare with the sprint goal. The purpose of the review is to describe what was accomplished and then to use the information to determine the best course of action for moving forward.

Demonstrate

I want to take a moment to caution you about the term demo or sprint demo. Although a demonstration is frequently a quite helpful part of a sprint review, it is not the aim of the review.

The most important aspect of the sprint review is the in-depth conversation and collaboration among the participants. Through these interactions, the Scrum team surfaces and exploits productive adaptations. The demo is merely a way to jump-start the conversation around something concrete.

Sometimes the team builds functionality that doesn't lend itself easily to a demo. That is not a valid excuse to exclude it from the demo. A team that gives it some thought, can always find a way to show stakeholders the work of the sprint.

Discuss

All sprint reviews should elicit vigorous discussion. Participants who aren't on the Scrum team should ask questions, understand the current state of the product, and help guide the product's direction with their feedback. The Scrum team should leave with a deeper appreciation for the business and marketing side of their product while getting feedback on the convergence of the product toward delighted customers or users.

As such, the sprint review is the perfect place to discuss observations, comments and feedback regarding the product and its current trajectory. It is not, however, the best venue for deep problem solving; that kind of work should be deferred to another meeting.

Adapt

Through demonstration and discussion, the Scrum team is able to ask and answer the following questions:

• Do the stakeholders like what they see?
• Do they want to see changes?
• Is what we're building still a good idea in the marketplace or to our internal customers?
• Are we missing an important feature?
• Are we overdeveloping/investing in a feature where we don't have to?

Asking and answering these questions provides input on how to adapt the product backlog and release plans. The sprint review gives teams an opportunity to identify ways to adapt, to respond to change, when it is still affordable to do so—at the end of every single sprint.

Section 4 : Sprint Planning

Contents:

SPRINT PLANNING

• PARTICIPANTS IN SPRINT PLANNING
• INPUTS TO SPRINT PLANNING
• OUTPUTS OF SPRINT PLANNING
• SPRINT PLANNING PROCESS

1. Determine Team Capacity
2. Sprint Planning Approach
3. Refine the Sprint Goal
4. Finalize the Commitment

Product backlogs typically contain much more work than can be completed in a single sprint. So, each sprint begins with sprint planning.

Sprint planning is a recurring, just-in-time activity that occurs at the beginning of each sprint, when the entire Scrum team gathers to agree on a sprint goal and to select a subset of product backlog items it can commit to accomplish during the sprint. For a two-week to month-long sprint, sprint planning should take no longer than four to eight hours to complete.

The participants, inputs, outputs, and basic process of sprint planning are shown in the image below.

PARTICIPANTS IN SPRINT PLANNING

The full Scrum team collaborates during sprint planning. This includes the development team, the product owner, and the ScrumMaster.

INPUTS TO SPRINT PLANNING

Sprint planning relies on a set of inputs that guide the development team in determining what value it can realistically deliver during the sprint. These sprint planning inputs are as follows:

Product Backlog
The highest priority PBIs should already be groomed, which typically means the PBIs have acceptance criteria, and have been sized appropriately, estimated, and prioritized.

Team Velocity
The team's historical velocity is one indicator of how much work is practical for the team to complete in a single sprint.

Constraints
The team should have identified any business or technical constraints that could materially affect what the team's can deliver.

Team Capabilities
The team should know which team members are available (and what their availability is) for this particular sprint, as well as which skills each team member has.

Initial Sprint Goal
The product owner should have identified the business objective he ideally would like to see accomplished during the sprint.

OUTPUTS OF SPRINT PLANNING

At the end of sprint planning, the development team communicates its commitment through the two sprint planning outputs: a finalized sprint goal and a sprint backlog.

SPRINT PLANNING PROCESS

The process of sprint planning can be accomplished in several ways, but in general there are two approaches to sprint planning: two-part sprint planning and one-part sprint planning. Both approaches begin with the team determining its capacity.

Determine Team Capacity

Put simply, a team's capacity is the estimated total number of hours the team will have available to work on product backlog items during the sprint, minus other regular sprint activities, non-sprint commitments, and planned time off. The capacity should take into account individual team member skills as well, especially highly specialized skills that might have very limited availability during a sprint. Most teams also reserve some buffer time against the unplanned and unexpected including but not limited to maintenance, run the business and impromptu meetings based on past experience.

Sprint Planning Approach

The development teams begins by determining its capacity to deliver work. Based on available capacity, the sprint goal may need to be refined. Next, the team selects the highest priority requested product backlog item and acquires confidence that the selected item will reasonably fit within the sprint, given other items already included in the team's evolving commitment. This cycle is then repeated in priority order until the team is out of capacity to do any more work. At that point, the team finalizes its commitment and sprint planning is over.

Refine the Sprint Goal

The sprint goal summarizes the business purpose and value of the sprint. The product owner comes to sprint planning with an initial sprint goal, but the sprint goal would be refined over the course of sprint planning to match the reality of what can be delivered during the sprint.

Finalize the Commitment

At the completion of sprint planning, the development team finalizes its commitment to the business value it will deliver by the end of the sprint. This commitment is expressed in a refined sprint goal and sprint backlog.

Section 5 : Sprint Execution

Contents:

• SPRINT EXECUTION
• OVERVIEW
• TIMING
• PARTICIPANTS
• PROCESS

1. Task Planning
2. Flow Management
3. Daily Scrum
4. Task Performance—Technical Practices
5. Communicating

Sprint execution is the work the Scrum team performs during each sprint to meet the sprint goal. The principles and techniques that guide how the Scrum team plans, manages, performs, and communicates during sprint execution are described below.

OVERVIEW

Every sprint, the team executes a mini-project unto itself—it performs all of the work necessary to deliver a potentially shippable product implement. The team's work is guided by the sprint goal and sprint backlog.

TIMING

The majority of the team's time each sprint should be spent in sprint execution. It begins after sprint planning and continues until the sprint review begins.

PARTICIPANTS

During sprint execution, the development team members self-organize to determine the best way possible to meet the sprint goal.

• The ScrumMaster coaches, facilitates, and removes any impediments that block or slow the team's progress.
• The product owner is available to answer questions, review intermediate work, and provide feedback to the team.
• The product owner might also be called upon to discuss adjustments to the sprint goal or to verify acceptance criteria.

PROCESS

Task Planning

During sprint planning the team produces a high-level plan for how to achieve the sprint goal, usually in the form of a sprint backlog. Team members perform just-in-time task-level planning as needed, as opposed to trying to formulate a detailed plan or Gantt chart.

Flow Management

The idea of flow management is to empower team. It is the team's responsibility to manage the flow of work throughout the sprint to meet the sprint goal. This includes making decisions about how much work the team should do in parallel, which work to start, how to organize the task-level work, which work to do, and who should do the work.

Parallel Work and Swarming

The team must determine how many product backlog items to work on in parallel(this is WIP limit, ideally not to exceed 2 items), in other words, at the same time. Working on too many items at once slows the team down. But working on too few items at once is equally wasteful.

The goal is to reduce the time required to complete individual items while maximizing the total value delivered during the sprint. Another name for this approach is swarming. Swarming is when team members with available capacity work together to complete one unfinished item rather than moving ahead to work on new items. This doesn't mean teams should always work on only one item at a time—the actual number of open items at any one time is highly dependent on context. Teams will have to experiment to find the balance that maximizes the value they deliver each sprint.

Which Items to Start

The simplest way to choose the product backlog item to work on next is to select the highest-priority item as specified by the product owner. Unfortunately, this doesn't always work. In reality, dependencies or skills capacity constraints might dictate a different order. The development team should be enabled to opportunistically select work as appropriate. This should ideally happen in Spring Planning meeting but sometimes they come up during daily standup and/or when the team or a team member is impeded or have realized something new.

How to Organize Task Work

It's tempting for new agile teams to approach task level work in a waterfall fashion: design it, code it, and then test it. It's better, however, to approach the work from a value and delivery-focused mindset. This means minimizing the amount of time work sits idle and reducing the size of handoffs. In practice, this sometimes looks like a developer and tester pairing at the start of a task to work in a highly interleaved fashion, with rapid cycles of test creation, code creation, test execution, and test and code refinement. This approach keeps work flowing, supports very fast feedback, and enables team members to swarm on an item to get it done.

What Tasks Needs to Be Done?

The team should decide which task-level work it needs to perform to complete a product backlog item. Product owners and stakeholders influence these choices by defining the scope of a feature and creating acceptance criteria. They also provide business-facing requirements for the team's definition of done. Overall, the team and the product owner must work together to ensure that technical decisions with important business consequences are made in an economically sensible way.

Who Does the Work?

Who should work on each task? An obvious answer is the person best able to quickly and correctly get it done. But based on team maturity this is negotiable for cross training and sustainability. Functional Manager or the team leads this discussion in planning meeting. And if that person is unavailable, the team should decide on the next best person.

Daily Scrum

The daily scrum is a critical daily inspect-and-adapt activity to help the team achieve sprint goal. It is a 15-minute, timeboxed activity that takes place once every 24 hours. The purpose of the daily scrum is to get the people who are focused on meeting the sprint goal together to share the big picture of what is happening so that they can collectively understand how much to work on which items to start working on, and how best to organize the work among the team members. It is essential for flow management.

“Taking a systemic view of product development where we organize and optimize the teams and other resources (the system) to pull WIP-limited quantities of appropriately-size work items into the system and quickly delivery value to the customer (fast), while adapting to the specific needs of developing novel, non-cookie-cutter solutions (flexible), the whole time relentlessly focusing on removing impediments that inhibit fast and flexible development (to achieve good flow). 2. Term used by Womack and Jones in their book Lean Thinking (1996).”

Task Performance—Technical Practices

Development team members are expected to be technically good at what they do. For example, if you are using Scrum to develop software, team members need to be skilled in good technical practices for developing software, such as continuous integration, automated testing, refactoring, test-driven development, and so on. Teams that fail to develop strong technical skills generally fall short of achieving the long-term benefits of Scrum.

Communicating

Scrum teams should use highly visible methods to communicate progress. Two of the most popular are a task board and a sprint burndown or sprint burnup chart.

Task Board

The task board is a simple but powerful way to comunicate sprint progress at a glance. The sample task board below lists each PBI and its associated tasks. The tasks remain in the To-Do column until the team starts work on them. Then, as the team begins work on a task, the team moves that task to an in-progress column, and eventually to the completed column.

Sprint Burndown Chart

The sprint burndown chart tracks how many hours of effort remain on each task, by day. Each day, the team updates its in-progress tasks with an estimate of how much work is remaining. It adds these task hours to the total number of hours estimated for any tasks that haven't yet been started and plots the results on the sprint burndown chart, as shown below. The sprint burndown chart is useful for tracking progress and can also be used as a leading indicator to predict when work will be completed. Note that sprint burndown charts always use estimated effort remaining. They do not capture actual effort expended.

Sprint Burnup Chart

A sprint burn-up chart is another way to visualize progress through a sprint. Often, sprint burn-up charts are plotted using story points. Each day, the sum of completed product backlog items to date, as measured in story points, is charted. Burnup charts allow teams to see at a glance how well (or how poorly) product backlog items are flowing through the sprint. An ideal burnup chart shows a steady rise in completed items from early in the sprint to the end of the sprint (see dark blue line in the figure below). If your burnup chart shows almost no progress in terms of completed items until the last few days of the sprint (see light blue line in the figure below), you should consider that a red flag.

Section 6 : Sprint Retrospective

Content:

Sprint Retrospective

• OVERVIEW
• SPRINT RETROSPECTIVE TIMING
• SPRINT RETROSPECTIVE PARTICIPANTS
• SPRINT RETROSPECTIVE PREWORK

1. Define Retrospective Focus
2. Select Exercises
3. Gather Objective Data
4. Structure the Retrospective

• SPRINT RETROSPECTIVE APPROACH

1. Set the Atmosphere
2. Create Shared Context
3. Identify Insights
4. Determine Actions

• DOT VOTING
• CLOSE THE RETROSPECTIVE
• FOLLOW THROUGH

OVERVIEW

Sprint retrospectives give the whole Scrum team an opportunity to stop for a moment and examine what's happening, analyze the way they work, identify ways to improve, and make plans to implement these improvements. Anything that affects how the team creates the product is open to scrutiny and discussion. Retrospectives are crucial because they give Scrum teams the chance to customize Scrum to their unique circumstances.

SPRINT RETROSPECTIVE TIMING

The sprint retrospective typically is the last activity of the sprint. It should generally recur at the same weekday, time, and place each sprint.

All retrospectives should be timeboxed; in most cases, a sprint retrospective should take between one hour and three hours, depending on sprint length. Do not spend less than one hour or more than four.

SPRINT RETROSPECTIVE PARTICIPANTS

The entire Scrum team (development team, ScrumMaster, and product owner) should attend the sprint retrospective. The development team includes everyone who is designing, building and testing the product. Collectively, the Scrum team members have the diverse perspectives necessary to reflect on the progress and suggest improvements.

On certain occasions, the Scrum team might also decide to invite people from outside the Scrum team if their insights or perspectives will contribute to team learning during the retrospective.

SPRINT RETROSPECTIVE PREWORK

Not all sprint retrospectives require prework. For short-duration sprints or for teams who are using a well-practiced format, little if any prework is required.

Define Retrospective Focus

The default retrospective focus is to review all relevant aspects of the process used during the previous sprint. However, sometimes teams want to alter the focus for a particular retrospective depending on what is important to the team and where improvements are needed. Some teams might want to focus on ways they can improve technical skills; others might want to problem solve ways to build features that better match customer expectations.

Establishing and communicating the focus of the retrospective ahead of time allows the team to determine if any non-Scrum members should be invited. It also allows the team to select appropriate retrospective exercises and gather any necessary data.

Select Exercises

Teams also need to choose exercises that will help them engage, think, explore, and make decisions. Some common exercises are to create and mine a sprint event timeline, brainstorming, and grouping and voting.

During prework, teams don't have to decide exactly which exercises they will use—they need only do enough research to have some exercise choices and materials and data available to support any of the potential exercises.

Gather Objective Data

Any legwork needed to collect data should happen before the retrospective. Objective data is hard data (not opinions), such as what events happened and when, counts of the number of PBIs that were started and not finished, or the feature burnup for the sprint. At this time, the data only needs to be collected, not analyzed.

Structure the Retrospective

Because retrospectives can vary in length, place, participants, and time, it's a good idea to review the desired structure as part of the retrospective prework. The exact length will depend on how many people are on the team, how new the team is, whether any team members are located remotely and so on.

SPRINT RETROSPECTIVE APPROACH

The tangible prework items (focus, exercises, and objective data) are inputs to the retrospective. Other inputs include subjective data and the insight backlog. Outputs include a list of improvement actions, the updated insight backlog, and improved camaraderie.

The team's approach to a sprint retrospective can be as simple as Scrum team members coming together to discuss questions such as

• What worked well this sprint that we want to continue doing?
• What didn't work well this sprint that we should stop doing?
• What should we start doing or improve?

Set the Atmosphere

Establish the atmosphere that makes people feel comfortable and safe. Find simple ways to get them talking.

Create Shared Context

A group of people can experience the same event and yet interpret it quite differently. To create a shared context among a team, first ground the retrospective by sharing objective data about the sprint. Then invite people to share subjective data—what were some things they observed during the sprint and/or how did they feel about the sprint?

Identify Insights

The participants next identify insights by collaboratively examining, interpreting, and understanding both the objective and subjective data. Doing this effectively requires a system-level focus, which helps teams find the root cause of issues.

Brainstorming is an excellent activity for capturing insights. Another source might be the team's insight backlog, a list of previously generated insights that have not yet been acted upon. The insight backlog is typically updated at the end of each sprint to reflect new insights.

Determine Actions

Once the team has identified their insights, they need to move from discussing them to taking demonstrable actions to leverage them.

Often, the team identifies more insights than it can address during any one sprint. When this happens, the team will need to prioritize the insights, perhaps through dot voting or some other prioritization activity. The team members will also need to determine how much capacity they will have for any improvement actions during the upcoming sprint.

Once the team has prioritized its insights and estimated its capacity, the team can define concrete, actionable steps to leverage the insights and improve the Scrum process. Most actions will take the form of specific tasks that one or more Scrum team members will perform during the upcoming sprint. Sometimes the actions represent impediments that the ScrumMaster might own but someone outside the Scrum team must resolve. Sometimes, teams discover that it isn't possible to immediately address the insight and have to choose instead to explore the insight. All of these actions can be tracked in the insight backlog.

Dot Voting

A technique that allows participants to vote their preferences among a set of items by placing a colored dot on items that they believe are higher priority than other items. Items with more dots are higher priority than items with fewer dots. This can also be achieved by asking team members to writing the insights and group them by theme and pick the most ranked theme.

Close the Retrospective

The last step is to close out the retrospective. Many do this by recapping the actions the team has decided to take based on what the participants learn. It is also a good time to appreciate people and their participation. I also recommend asking the team for suggestions to improve future retrospectives. A retrospective is, after all, part of the Scrum framework and as such should also be subject to inspection and adaptation.

FOLLOW THROUGH

To ensure that what happens in the sprint retrospective does not just stay in the sprint retrospective, the participants should follow up on the actions they choose to complete. Frequently the easiest way to handle the improvement actions is to populate the sprint backlog with tasks corresponding to each action prior to bringing in new features. The teams available capacity to work on new features would then be adjusted downward by the estimated time these improvement tasks will take.