Planning and Managing Iterations

How to Plan a Sprint

Sprint planning happens at the start of each sprint. In this working meeting, the team agrees on what it is trying to accomplish, what work it will take on, and how it will get started.

A typical sprint planning session covers five activities:

• Define the sprint goal. Agree on a clear, focused goal that explains what the sprint is meant to accomplish and why it matters.
• Select the backlog items. Choose items that support the sprint goal, taking into account priority, dependencies, risk, and available capacity.
• Break selected stories into tasks. Discuss how the work will be completed and break stories into smaller tasks that can be assigned, estimated, and tracked.
• Estimate the sprint work. Estimate the tasks needed to complete the selected items, including testing, review, documentation, and other work required to meet the Definition of Done. Use these estimates to check whether the plan fits the team’s realistic capacity.
• Commit to the sprint. Commit to the intended sprint outcome and the value it provides.

By the end of sprint planning, you should be able to answer three questions: What are we trying to accomplish? What work are we taking on? How will we approach it?

Define the Sprint Goal

A sprint goal is a short statement that summarizes what the team is trying to accomplish during the sprint. It describes the main outcome or focus of the sprint, not just the list of backlog items the team plans to complete.

A useful sprint goal gives the sprint a clear purpose. It helps the team and stakeholders understand why the selected work matters and how the sprint moves the product forward. The goal should be specific enough to guide planning, but not so detailed that it simply repeats every backlog item.

For example, instead of setting a sprint goal like:

Complete stories 12, 13, and 14.

A stronger sprint goal might be:

Enable alumni staff to create and publish basic event listings.

This goal summarizes the value of the sprint more clearly. The related backlog items might include creating the event form, saving event details, publishing an event, and displaying published events in the alumni portal.

Select the Backlog Items

When selecting backlog items, choose ones that support the sprint goal and fit your realistic capacity. Assuming items have been refined and are ready to work on, priority is usually the next consideration. A lower-priority item is sometimes the better choice when it supports the sprint goal, reduces risk, or prepares you for upcoming work. If an item still feels unclear or too large at planning, send it back to refinement rather than pulling it into the sprint.

When selecting backlog items, the team should ask:

• Does this item support the sprint goal?
• Is it clear enough to begin?
• Is it small enough to complete during the sprint?
• Are the dependencies understood?
• Do we have the capacity and skills to complete it?
• Does it introduce risk that should be addressed now?

The selected items become the starting point for the sprint plan. The team will then break them into tasks, estimate the work, and check whether the overall plan is realistic.

Break Selected Stories into Tasks

Once a story is selected for the sprint, the team breaks it into the specific pieces of work needed to deliver it. Each piece becomes a task, a unit of work small enough that one person can usually complete it in roughly four to eight hours.

Task breakdown matters because it helps the team think through what “done” actually requires before the work begins. It surfaces hidden work, such as testing, data changes, documentation updates, approvals, accessibility checks, or deployment steps. It also helps the team share responsibility and track progress day to day.

To break a story down, the development team walks through it together and identifies what needs to be designed, built, integrated, tested, documented, approved, or deployed. They capture each distinct piece of work as a task.

Useful tasks are typically:

• Small. They can usually be completed within four to eight hours of effort.
• Specific. They describe a clear piece of work needed to build, test, or integrate the story.
• Linked to a story. Each task rolls up to its parent story, so the team can see what user value the task supports.

When breaking down a story, teams should include all work needed to finish it, not just the coding tasks.

Example Tasks

Consider this user story: “As an event organizer in the university’s alumni office, I want to create and publish alumni events so that alumni can see details and sign up.”

Broken down, the story might produce tasks like these:

• Design the Create Event form.
• Build the backend data model and API endpoints for events.
• Implement draft versus published states and the preview view.
• Update the alumni portal to list published events.
• Add input validation and confirm accessibility.
• Write unit tests and run a performance test for the events listing page.
• Verify email notifications and role-based access.

Notice that the breakdown includes more than coding. Testing, accessibility, notifications, and access control all need time. When teams miss this supporting work during planning, sprints are more likely to slip.

Estimate the Sprint Work

In Chapter 7, backlog items were estimated using relative measures such as story points which help you compare items, prioritize work, and plan ahead.

During sprint planning, estimation becomes more concrete. The team reviews the selected stories, breaks them into smaller tasks, and checks whether the work fits within the sprint.

These task estimates are often expressed in hours, ideal hours, or similar units because they help the team plan the sprint, coordinate work, and check capacity (Cohn, 2005).

At this stage, estimation helps the team answer four questions:

• What work is required to complete each selected story?
• How much effort will the sprint work require?
• Where are the risks, dependencies, or unknowns?
• Does the plan still look achievable given the team’s available capacity?

This may include design, development, testing, accessibility checks, documentation, review, deployment steps, stakeholder feedback, and anything else required by the team’s Definition of Done.

These estimates are still shaped by the same factors introduced in Chapter 7:

• Effort: how much work is required.
• Complexity: how difficult the work is.
• Uncertainty: what the team does not yet know.

Breaking stories into tasks helps the team see the work more clearly. It can reveal missing steps, hidden dependencies, unclear requirements, or assumptions that were not obvious when the story was estimated at the backlog level. If the work looks too large or uncertain, the team should adjust before the sprint begins by reducing scope, splitting a story, resolving a dependency, or moving lower-priority work out of the sprint.

Check Capacity and Finalize the Sprint Plan

After estimating the selected work, the team checks those estimates against actual capacity. This is where the team tests whether the sprint plan is realistic, not just whether the selected stories are important.

The team should compare the estimated work with the time, attention, and skills realistically available during the sprint. If the plan looks too large, the team should adjust scope before the sprint begins. That might mean removing a lower-priority story, splitting a story, reducing scope, or resolving a dependency before the sprint begins.

The final sprint plan should include:

• The sprint goal.
• The selected backlog items.
• The tasks needed to complete them.
• Initial task estimates.
• Known risks, dependencies, or assumptions.
• A shared understanding of how the team will begin the work.

A good sprint plan gives the team enough clarity to get started, make progress, and deliver something useful for users and stakeholders.

Use the Definition of Done

Before the team finalizes a sprint plan, it should be clear what “done” means. A Definition of Done is a shared agreement about what must be true before the team considers a backlog item complete. It helps the team avoid treating work as finished when it has only been coded, but not yet tested, reviewed, documented, integrated, or accepted.

The Definition of Done applies across the team’s work and creates a consistent standard for quality. Individual stories may have their own acceptance criteria, but the Definition of Done describes the baseline expectations that every completed item should meet.

A typical Definition of Done might include conditions such as:

• Acceptance criteria have been met.
• Code has been reviewed.
• Tests have passed.
• Accessibility checks have been completed where relevant.
• Security, privacy, or compliance requirements have been addressed.
• Documentation or release notes have been updated where needed.
• The work has been integrated and is ready to demonstrate.
• The product owner or appropriate stakeholder has reviewed the item where needed.

Acceptance criteria and the Definition of Done work together, but they are not the same. Acceptance criteria describe what must be true for a specific backlog item to satisfy the need it addresses. The Definition of Done describes the broader quality standard that applies across completed work.

For example, a story about alumni event registration might include acceptance criteria such as “users can register with one click” or “the system prevents registration after the event reaches capacity.” The Definition of Done adds broader expectations, such as testing, code review, accessibility checks, documentation updates, and integration. A story is complete only when it meets both its own acceptance criteria and the team’s Definition of Done.

The Definition of Done should be visible during sprint planning and used throughout the sprint. When the team estimates work, it should include everything required to meet the Definition of Done, not just the coding task. During the sprint demo, only work that meets the Definition of Done should be presented as complete. Work that does not meet the Definition of Done may still be discussed, but it should be clearly labeled as in progress.

Definition of Ready vs. Definition of Done

The Definition of Ready and the Definition of Done serve different but complementary purposes. The Definition of Ready describes what a backlog item needs before it enters a sprint. The Definition of Done describes what the item must meet before it can be considered complete.

Think of them as entry and exit criteria for a sprint. The Definition of Ready helps the team define work that is clear, small enough,and practical to complete within the sprint, while the Definition of Done helps deliver work that is complete to stakeholders..

Tracking Development During the Sprint

Using Daily Stand-ups to Coordinate Work

A daily stand-up is a short meeting, usually about 15 minutes, where the team checks whether the sprint is still on track. During stand-up, team members identify:

• What was accomplished since the last stand-up.
• What will be worked on before the next stand-up.
• Anything blocking them from making progress.

Many backlog management tools, such as Azure DevOps and Jira, include sprint boards that group and track tasks associated with each user story. This helps visualize the status of each story during the sprint.

As team members update remaining work on the board, the team can quickly assess whether it is on track to meet the sprint goal.

Use Burndown Charts to Track Progress

A burndown chart shows how much work remains compared with how much time is left in the sprint. It starts with the total planned work and is updated as tasks are completed. As work is finished, the “work remaining” line should move downward.

The vertical axis shows work remaining, often measured in story points or hours. The horizontal axis shows the days in the sprint. This helps the team see whether progress is steady or whether the sprint may be drifting off track.

For example, a line that stays flat for several days, drops suddenly, or moves far from the ideal line may signal blocked work, hidden complexity, or estimates that need to be revisited.

This helps teams see progress more clearly, coordinate work, and build confidence that the sprint is moving in the right direction.

Completing and Reviewing the Iteration

Sprint Demonstration (Demo)

A sprint demo is a meeting at the end of a sprint where the team shows completed work to stakeholders. The purpose of the demo is to help stakeholders see what has been built, ask questions, give feedback, and discuss whether the product is moving in the right direction. This feedback may influence future backlog items, roadmap decisions, or sprint priorities (Schwaber & Sutherland, 2020).

How to Run a Sprint Demo

To run an effective sprint demo, treat it as a working conversation about the product rather than a presentation about the team’s activity. Start by clarifying the goal of the session, what completed work will be shown and what feedback the team needs from stakeholders.

Demonstrate the work using realistic user scenarios so stakeholders can see how the product supports user needs and tasks. Keep the session focused, invite questions, capture feedback, and close by summarizing any follow-up actions, backlog updates and focus for the next sprint.

A simple agenda for a sprint demo includes:

• Purpose and sprint goal
• Completed items that will be shown
• Demonstration of each item
• Stakeholder feedback
• Summary and next steps

Prepare Ahead

A good demo requires some preparation. Before the meeting, confirm which items are actually done and ready to show. Do not demo unfinished work as if it were complete. If you want to show something still in progress, label it clearly so stakeholders understand what they are seeing.

Create a short script or set of scenarios to guide the demonstration. This does not need to be formal, but it should help the team avoid wandering through features without context.

Before the session, set up the environment, test logins, prepare sample data, and check that any integrations or tools needed for the demo are working. It is also useful to have a backup plan, such as screenshots, a short recording, or a second environment, in case something breaks during the live demo.

Keep It Focused

A sprint demo should focus on what changed and why it matters. Demonstrate the work from the perspective of a user or stakeholder. Instead of walking through every technical detail, show how someone would use the feature to accomplish a task.

For example, rather than saying, “We updated the approval logic,” you might say, “Here is what a manager now sees when an employee submits a purchase request that exceeds the department threshold.” This keeps the demo grounded in workflow, value, and use.

Technical details can still be included when they matter to the audience. Stakeholders may need to understand performance, security, data quality, compliance, or integration constraints. The key is to connect those details to product value or risk, rather than turning the demo into a technical deep dive.

Have the Team Demonstrate the Work

Whenever possible, the people who worked on an item should help demo it. This gives team members recognition, helps stakeholders hear from the people closest to the work, and reinforces shared ownership of what was delivered.

Encourage Stakeholder Feedback

Stakeholders should be invited to ask questions, react to what they see, and identify gaps or concerns. The team should listen for both direct feedback and indirect signals, such as confusion, hesitation, or requests for clarification.

Use open-ended questions to guide discussion:

• Does this support the workflow you expected?
• What would make this easier to use?
• What is missing for this to be useful in practice?
• Are there situations where this would not work well?
• Does this change any priorities for the next sprint?

Avoid treating every comment as an immediate change request. Capture feedback where the team can review it later.

Timebox the Session

Timebox the session so it stays focused and respects attendees’ time, a maximum of four hours for a one-month sprint, with shorter sprints usually needing shorter reviews (Schwaber & Sutherland, 2020).

Provide a Summary and Define Next Steps

Close by summarizing what was demonstrated, what feedback was received, and what will happen next. This helps stakeholders see how their input will be used.

The wrap-up might include:

• Items accepted as complete
• Feedback that may become new backlog items
• Questions that need follow-up
• Impacts on priorities, roadmap, or release planning
• Any risks, dependencies, or decisions that need attention

A successful demo helps stakeholders understand the current state of development and gives the team feedback it can use to refine the backlog and prioritize what to tackle next.

Sprint Retrospective

The Sprint Retrospective is a dedicated meeting where the team reflects on the most recent sprint and identifies ways to improve how it works. The focus is not only whether the sprint goal was met, but also how communication, processes, tools, collaboration, and working agreements supported or limited the team’s effectiveness (Schwaber & Sutherland, 2020).

How to Run a Sprint Retrospective

Retrospectives work best when they are focused, constructive, and tied to a small number of changes the team can actually make.

Set ground rules and timebox the meeting.
Start by reminding the team that the purpose is to improve, not to blame. Retrospectives should focus on the conditions that shaped the work: communication, process, tools, priorities, dependencies, and collaboration. This no-blame framing matters because teams learn more effectively when people feel safe raising concerns, mistakes, and uncertainties (Edmondson, 1999; Kerth, 2001).

Most retrospectives can be completed in 30–60 minutes, depending on sprint length and team size.

Use a simple structure to guide the conversation.
A basic format is often enough:

• What went well?
• What did not go well?
• What should we improve?

This structure helps you create the right setting, gather input, generate insights, decide what to do, and close with clear next steps (Derby & Larsen, 2006).

Encourage equal participation.
A retrospective should not be dominated by the loudest or most senior voices. Give everyone a chance to contribute, especially people whose work may have been less visible during the sprint. Sticky notes, whiteboards, shared documents, or digital tools can help collect input before discussion begins. Round-robin or time-boxed sharing can also help if participation is uneven.

Keep the focus on improvement.
Keep the discussion constructive. Instead of asking, “Who caused this problem?” ask, “What made this problem more likely?” or “What can we change so this is easier next time?” This shifts the conversation from personal fault to process improvement.

For example, if several stories were not completed, the useful question is not whether someone worked hard enough. The useful question is whether the stories were too large, acceptance criteria were unclear, dependencies were missed, or the team took on too much work. Coordination, team orientation, and communication problems can all get in the way of effective agile work, which makes them useful topics for retrospectives (Moe et al., 2010).

Identify actions.
A good retrospective does not need a long list of improvements. One to three concrete action items are usually more useful than a large list the team cannot realistically complete. Each action item should be specific enough to try in the next sprint, visible to the team, and assigned to someone responsible for follow-up.

Examples include:

• Break large stories down before sprint planning.
• Add acceptance criteria before a story is pulled into a sprint.
• Hold a short dependency check halfway through the sprint.
• Move design review earlier in the workflow.
• Clarify who responds to stakeholder questions.

Follow up.
Begin the next retrospective by reviewing the previous action items. Ask what changed, what did not, and whether the action helped. This follow-up matters because it shows that feedback leads to real change. Without follow-up, retrospectives can become performative. With follow-up, they become part of the team’s continuous improvement cycle.

Best Practices

The following practices help keep sprint planning and management realistic, collaborative, and focused on delivering useful increments of work.

• Limit work in progress.Taking on too much is one of the most common sprint planning mistakes. Select work that fits within the team’s realistic capacity, not its theoretical maximum. A sprint that finishes three stories well is more valuable than one that half-finishes six.
• Use historical data to inform estimates. Compare past estimates with actual outcomes to improve future planning. Over time, this gives the team a clearer picture of what it can realistically deliver in a sprint.
• Distinguish effort from duration. A task may require four hours of focused work but take two days once meetings, reviews, and dependencies are accounted for. Planning that ignores this gap leads to overcommitment.
• Use the sprint goal to guide trade-offs. When unexpected work comes up during the sprint, compare it with the sprint goal. Work that supports the goal may justify adjusting the plan. Work that does not should usually be captured in the backlog for later.
• Close the feedback loop. Demos and retrospectives improve the product and the process only when feedback is captured, reviewed, and acted on. Track action items the same way you track backlog work.

Wrap up

Iterations are where you take goals, user needs, and requirements and turn them into work the team can deliver. Through the sprint, the team estimates the work, commits to a sprint goal, tracks progress, demonstrates what was completed, and reflects on what to improve next.

In the next chapter, we explore how to deploy what you’ve built and support them reliably once in production.