All in One View
Content from Learning Objectives
Last updated on 2026-06-18 | Edit this page
Learning Objectives
Product Discovery & Initial Backlog Creation
- Understand how to initiate a project and gather initial requirements
from stakeholders
- Define a Product Vision and identify key users
- Map user journeys and activities
- Create an Initial Product Backlog as a User Story Map
- Break features into Epics and User Stories
- Prioritise backlog items using MoSCoW
- Learn Release planning and plan a Minimum Viable Product (MVP)
- Prepare a Product Backlog ready for first Sprint Planning
Sprint Planning
- Understand the purpose of Sprint Planning in Scrum
- Define a Definition of Done (DoD)
- Create a Sprint Goal using SMART criteria
- Identify candidate backlog items for the sprint
- Estimate stories using Story Points and Planning Poker
- Validate Sprint scope and team capacity
- Create a Sprint Backlog using a Kanban board
- Commit to a realistic Sprint plan
Sprint Development Work
- Understand the purpose of Sprint Development Work
- Select and assign user stories from the Sprint Backlog
- Use a Kanban board to track Sprint progress
- Apply Work-In-Progress (WIP) limits to manage workflow
- Handle blocked stories during development
- Ensure work meets the Definition of Done (DoD)
- Collaborate effectively as a Scrum development team
Sprint Review
- Understand the purpose of the Sprint Review meeting
- Prepare and conduct a Sprint Review session
- Demonstrate completed product increments
- Collect stakeholder feedback on delivered features
- Record bugs and enhancement ideas in the Product Backlog
- Evaluate Sprint Goal achievement and alignment with Product
Vision
- Recognise team achievements and identify improvements
Sprint Retrospective
- Understand the purpose of the Sprint Retrospective
- Reflect on what went well and what challenges occurred during the
sprint
- Analyse team processes, tools, and collaboration
- Review and improve the Definition of Done (DoD)
- Identify and prioritise key improvement areas
- Create actionable improvement plans for future sprints
- Support continuous improvement within the Scrum team
Product Backlog Refinement
- Understand the purpose of Backlog Refinement in Scrum
- Review and update the Product Backlog
- Break large stories into smaller, actionable User Stories
- Ensure top stories are clear and ready for Sprint Planning
- Reprioritise backlog items using MoSCoW
- Extend the MVP to support additional key users
- Prepare refined stories for the next Sprint Planning
Content from Outline and Agenda
Last updated on 2026-10-14 | Edit this page
Outline
- You are going to spend the day being part of a Scrum Team, working together on a micro-project.
- We will be adopting the various Scrum roles as defined in the reference section. In this course,
you will be working in Scrum Teams and will assume the following three
Scrum roles:
- Scrum Master: Each team will have one Scrum Master. Participants who express interest in this role will act as the Scrum Master. The expected responsibilities are here
- Product Owner (P.O): Each team will have one P.O. In some cases, participants who express interest in this role will act as the P.O. The P.O represents the Stakeholders, who are only “lightly engaged” with the process, and will help you clarify requirements as needed. The expected responsibilities of the P.O are here.
- Developer. The remaining participants in each team will act as Developers. The expected responsibilities are here.
- Where this course is different to a real project, is that we also have people acting a Facilitator. This is not a Scrum role but for the purposes of this course, Facilitators will ensure that their group is running to schedule, answer any course-related questions and will also assume the role of Product Owner when required.
Agenda Internal Course Run (UoM RSEs)
| Time | Item |
|---|---|
| PART 1: Agile Basics | |
| 9:30-10:00 | Introduction to Agile |
| PART 2: Practical Work | |
| 10:00-10:10 | Setup/Adjustment Time |
| 10:10-11:10 | Product Discovery |
| 11:10-11:20 | Coffee & Questions |
| 11:20-11:50 | Sprint 1: Planning |
| 11:50-12:05 | Sprint 1: Development Work |
| 12:05-12:25 | Sprint 1: Review |
| 12:25-13:15 | Lunch & Netwroking |
| 13:15-13:30 | Sprint 1: Retrospective |
| 13:30-14:40 | Sprint 2 (Backlog Refinement 10 mins, Planning 20 mins, Dev 15 mins, Review 15 mins, Retro 10 mins) |
| 14:40-14:50 | Coffee & Questions |
| 14:50-16:00 | Sprint 3 (Backlog Refinement 10 mins, Planning 20 mins, Dev 15 mins, Review 15 mins, Retro 10 mins) |
| 16:00-16:07 | Quick Break |
| 16:07-16:30 | Course Recap & Close |
Agenda External Course Run (outside UoM RSEs)
| Time | Item |
|---|---|
| PART 1: Agile Basics | |
| 9:30-10:15 | Introduction to Agile |
| PART 2: Practical Work | |
| 10:15-10:20 | Setup/Adjustment Time |
| 10:20-10:30 | Walk Teams through the Scrum Wall |
| 10:30-11:00 | Product Discovery Part 1 (before break) |
| 11:00-11:10 | Coffee & Questions |
| 11:10-11:50 | Product Discovery Part 2 (after break) |
| 11:50-12:30 | Sprint 1: Planning |
| 12:30-13:15 | Lunch & Netwroking |
| 13:15-13:30 | Sprint 1: Development Work |
| 13:30-13:50 | Sprint 1: Review |
| 13:50-14:05 | Sprint 1: Retrospective |
| 14:05-14:20 | Sprint 2 Backlog Refinement |
| 14:20-14:40 | Sprint 2: Planning |
| 14:40-14:50 | Coffee & Questions |
| 14:50-15:05 | Sprint 2: Development Work |
| 15:05-15:20 | Sprint 2: Review |
| 15:20-15:35 | Sprint 2: Retrospective |
| 15:35-15:40 | Quick Break |
| 15:40-16:00 | Course Recap |
| 16:00-16:30 | How the UoM RSE Department adapts and applies Agile + Any Questions |
Scrum Development Cycle Overview
As we explained in the slides in part 1 of this course, Scrum encourages the mindset where change is the norm and allows the (software) development process to embrace that change. The Scrum methodology fulfils this philosophy by using Sprint Cycles. Each Iteration (sprint) last 2-4 weeks, and gives the Stakeholders and Product Owner a chance to update priorities for the following sprint.
Image Source: Agile Methods for
RSEs
The following slide, shows the key Scrum Roles.
Image Source: Agile Methods for
RSEs
- You will be working on a Scrum Team of Developers for the day.
- All attendees will fulfil the Developer role at some point.
- Most attendees will also fulfil the Scrum Master role at some point.
- Some attendees will also fulfil the Product Owner role.
- The Facilitator is a role specific to the training course and can take on the Product Owner role if needed, in addition to keeping the Scrum Team on schedule.
Content from Getting a Scrum Project Started
Last updated on 2026-10-14 | Edit this page
Overview
Questions
- What is a Product Vision and how does it guide product development?
- How do we create the Product Backlog as a User Story Map?
- How do we prioritise User Stories and plan the Minimum Viable Product (MVP)?
Objectives
Main Goal:
- To get hands-on experience in planning and starting the Agile product development: from understanding the Product Vision to creating and prioritising a collaborative Product Backlog.
Learning Objectives:
Understanding a Product Vision, including the product’s purpose, value, and end users.
Identify and prioritise user personas, in order to prioritise high value.
Learn how to create the Product Backlog as a User Story Map by breaking down user activities into Epics and User Stories.
Know how to write actionable User Stories with acceptance criteria using Gherkin syntax.
Learn how to prioritise User Stories using MoSCoW labels and plan releases, including the Minimum Viable Product (MVP).
Gain practical experience collaborating as a team to plan, structure, and start an Agile product incrementally.
3.1. Defining the Product
3.1.1. Product Visioning
In Agile, projects don’t start with long requirement documents. Instead, they begin with a Product Vision. The Product Vision explains the purpose of the product, the value it should deliver, and the people it is intended to serve.
The Product Vision is usually introduced by the Product Owner at the start of a project to give everyone a shared sense of direction. It is owned by the Product Owner, but shaped together with stakeholders, customers, and business goals. The vision then acts as a guiding “north star”, helping the team stay focused throughout development.
A good Product Vision is built incrementally, with plenty of opportunities for inspection and adaptation as the product evolves. It is a stand-alone, transparent reference point that allows both stakeholders and the Scrum Team to clearly understand the product’s overall intention.
Challenge 1: Understanding the Product (15 minutes)
Step 1: Facilitator/PO Briefing (5 minutes)
- The Product Owner (PO) presents the Product Vision (using the product vision document provided by the organisers).
Team Listening Task While the PO shares the vision, the rest of the team listens actively and notes down:
- What they think the purpose of the product is.
- What they think the core value the product will deliver is.
- Who are the end users — the people who will directly use the product? Identify the different user types (personas).
- Who are the stakeholders — the people or groups who have an interest in, are affected by, or can influence the product, even if they do not use it directly?
Step 2: Reflection & Discussion (10 minutes)
- Each team member shares their notes with the group and engages in a group discussion.
- The group discusses:
- Whether the vision was clear.
- Whether they can correctly identify the purpose, core value, end users (personas), and stakeholders.
- At the end of the discussion, the team should commonly agree on what
they understood from the PO’s briefing about:
- Purpose of the product
- Core value it will deliver
- End users
- Stakeholders
- Team members can ask questions to the Facilitator or PO to clarify anything.
3.2. Product Backlog Creation as User Story Mapping
At this point, the Product Vision is clear — the why and who of the product — the next step is to move towards the what. We need a structured way of capturing the key insights about:
- the people who will use the product,
- their needs,
- the possible solutions to meet those needs, and
- the minimum viable product (MVP).
To do this, we use User Story Mapping.
User Story Mapping is a visual representation of the steps a customer takes when interacting with a product, from start to finish. It captures all the tasks a user would typically complete as part of their journey.
Through User Story Mapping, we translate our understanding of users and their journeys into tangible backlog items. Each step in the user journey becomes a potential user story that describes how the product should support the user’s goals. This forms the foundation of the Product Backlog — a prioritised, value-focused collection of work items derived directly from the customer experience.
It also serves as a collaborative backlog creation tool, enabling the Scrum Team and stakeholders to jointly build the initial Product Backlog. In this way, rather than beginning with a long, disjointed list of tasks, the backlog starts as a shared visual map that illustrates how the product will deliver value, guide release planning, and lead the team towards the first release or Minimum Viable Product (MVP).
In Agile, the responsibility for creating the Product Backlog and writing user stories primarily lies with the Product Owner (PO). It is not necessary for a PO to create the backlog personally – he or she may instruct the development team and/or the Scrum Master to help him/her in defining the backlog items and in estimating them.
Here, we want to make backlog creation a joint effort. This approach ensures genuine collaboration between the business, domain experts, and engineering, allowing the team to leverage the knowledge and expertise of all parties involved.
Now that we’ve established the importance of a collaborative approach, it’s time to put it into action. In the next section, we’ll explore how a User Story Map is structured. Through practical exercises, you’ll identify user activities, map user stories, and see how these form the foundation of the Product Backlog.
3.2.1. Structure of User Story Map
A User Story Map consists of two main layers. The top layer (backbone) displays main user actions, while the bottom layer contains detailed breakdowns of these actions.
1. The Backbone
The backbone forms the foundation with two key elements:
- User Activities
- Steps (Epics)
2. Release Slices
Release slices help organize your work into complete, usable features that can be delivered incrementally:
- The first slice should include the minimum set of features (MVP) that solves the core user problem.
- Subsequent slices add additional features over time.
- Each slice should deliver clear value to the user.
Your first slice (MVP) should focus on solving the user’s core problem.
3. Horizontal Organisation: Mapping Width (the User’s Journey)
The horizontal axis of a User Story Map represents the sequence of steps users take as they interact with your product—think of it as the width of the journey.
- Activities: Represent the high-level goals in the user journey, arranged left to right in the order users complete them.
- Epics: Break down each activity into more detailed steps, also arranged left to right beneath their corresponding activity to reflect the order of work.
4. Vertical Organisation: Mapping Depth
The vertical layout represents the ‘depth’ of each epic (what it takes to make each step happen):
- User Stories: Detailed work required to complete an epic, stacked vertically beneath the corresponding epic in priority order, with higher-priority items near the top and lower-priority items below.
- Swimlanes: Horizontal bands that slice the story map vertically, representing planned product releases or iterations (you can see an example in the USM Structure Diagram). We will cover them in detail in the Prioritisation of User Stories & Release Planning section later in this chapter.
Key Point: “Width” shows the sequence of the user journey on the User Story Map, while “Depth” shows the detailed work required at each step.
3.2.2. Core Components of User Story Map Structure
A User Story Map is composed of several essential elements that, when combined, give a clear and complete picture of your product:
- User Personas: Representations of the different types of users your product serves.
- User Activities: The main actions users take to achieve their goals.
- Epics: Large groups of related tasks or features that support user activities.
- User Stories: Specific, actionable pieces of work that describe what the user needs.
- Release Slices: Horizontal groupings of stories that plan incremental product releases.
We’re going to explore each part of the User Story Map and see how it helps us build a Product Backlog. To make things easier to follow, we’ll use a sample product — ‘The Rental Booking Product’ (similar to Booking.com or Airbnb) — just to show you how each step works. This is only for illustration. After each step, you’ll then practise by applying the same method to our real product. By the end, you’ll have created your own initial Product Backlog as a User Story Map.
i. Define User Personas
We start our User Story Map by defining the User personas. User Personas are fictional representations of your actual users. They help teams deeply understand who they are building for [Atlassian].
Example: Consider a ‘Rental Booking’ product, e.g. Booking.com/Airbnb:
The possible personas for Rental Booking product are listed below:
- Traveller/Guest
- Host
- Admin
The most important persona for The Rental Booking is usually the guest (the traveller) — because they are the primary driver of usage and revenue. Without guests, there will be no bookings and the platform won’t function.
Now that you have identified the different users of the product (in Challenge 1), it’s time to make some tough decisions. In the real world, teams rarely have unlimited time, budget, or resources to satisfy everyone at once. Agile encourages us to focus on delivering the highest value first — which means deciding whose needs matter most at the start.
Note: Complete challenge 2 below only if more than one persona has been identified by the PO for the product in Challenge 1 above. The Facilitator will confirm whether the team should undertake this challenge.
Challenge 2: Ranking the User Types / Personas for the required product (5 minutes)
As a team, rank the identified users by importance.
Decide:
- Which user must we satisfy first for the product to deliver
real value?
- Consider trade-offs: If resources are limited, whose needs could
reasonably be postponed until later without undermining the product’s
core purpose?
- Discuss and agree on a shared ranking in your team.
Further Instructions
- Scrum Masters: Ensure that all members of the team are involved.
ii. Define User Activities
The backbone of a User Story Map represents the key actions users take while interacting with product. These top-level actions, often referred to as user goals, provide the framework for organising the rest of the map.
How to define effective user activities?
- Centre on user goals: Think about what the user is trying to achieve, not just the features you plan to build.
- Sequence logically: Lay out activities in the order a user would naturally perform them.
- Organize related actions: Group similar activities together to create a clear, structured view.
User activities explain the purpose behind your development, while the underlying tasks and user stories provide the specific steps and details needed to deliver it.
Example: User activities for the the ‘Rental Booking’ product are demonstrated in the picture below:
iii. Identify Epics (Steps) from User Activities
Beneath every user activity, you define the larger features or work areas called epics that help achieve that activity.
- Epics are large bodies of work, often spanning multiple sprints.
Defining epics allows you to:
- See the full scope of work involved
- Prioritize tasks based on the value they deliver to users
- Plan and allocate resources more effectively
Example: Epics for the ‘Rental Booking’ product — see the row labeled “Epics” in diagram below
iv. Break Down Epics into User Stories
User stories describe specific features or requirements from the perspective of the user. They explain who needs it, what they need, and why it matters. Epics group related User Stories into higher-level feature areas. Breaking down an Epic into User Stories helps the team define smaller, actionable pieces of work that can be planned, developed, and delivered incrementally.
Example: Break down of Epics into User Stories for the ‘Rental Booking’ product
The relationship between activities, epics, and user stories is the heart of your story map.
💡Tip:
- Activities: Usually noun phrases describing phases.
- Epics: Usually verb + object, describing a goal.
- User Stories: Usually verb + object, describing an action.
The text in each User Story box in the diagram shown above is a short User Story title capturing the main action (2–3 words). We will look into adding in the full details, including Description, Acceptance Criteria, and best practices, as we proceed below.
To ensure high-quality User Stories, it’s important to follow a few widely accepted rules:
- Use a consistent format for a User Story structure
As a <user role>,
I want <activity>
so that <business value>See the example given in the figure below for the ‘Rental Booking’ product.
- Acceptance criteria - Acceptance Criteria are conditions that a product must satisfy to be accepted by a user, customer or other stakeholder. These are best written using the Cucumber language and Gherkin syntax.
Given <condition>
When <trigger>
Then <result/outcome>See the example of Acceptance Criteria given in the figure below for the ‘Rental Booking’ product.
-
INVEST helps to remember a widely accepted set of
criteria, or checklist, to assess the quality of a user story.
- I (Independent)
- N (Negotiable)
- V (Valuable)
- E (Estimable)
- S (Small)
- T (Testable)
Example: User Stories with the Acceptance Criteria for a ‘Rental Booking’ product:
Connecting user stories to the higher-level activities and epics on your map provides critical context.
Challenge 3: Create User Story Map for the product (15 minutes)
Step 1: Brainstorm User Activities
- Focus on the identified user persona. If multiple personas were identified in Challenge 1, focus on the top-priority persona identified in Challenge 2.
- Identify the big things this user needs to do
(Activities).
- Arrange Activities left-to-right in chronological order , this creates the “backbone” of the story map.
Step 2: Break Activities into Epics
- For each Activity, define Epics (bigger goals within the Activity).
- Online participants: Add an identifier for Epics (e.g. “E01”), and label any associated User Stories or tasks accordingly (e.g. “E01-01”).
Step 3: Break Epics into User Stories
- Write User Stories (specific actions to achieve the epic)
under each Epic.
- For the purpose of this course, at this point just add the title of the User Story and avoid any technical details or Acceptance Criteria at this stage. We will write these details after we have discussed prioritisation and release planning in the next section.
- This builds the vertical dimension of the map (from abstract goals to concrete actions).
Step 4: Review and Refine User Stories
- Review the User Stories created in Step 3. If a User Story is too large or covers multiple actions, break it down into smaller, more manageable User Stories. Use the INVEST criteria as a brief guide to check the quality of your User Stories.
Further Instructions
- In-person participants: use Post-it notes on a wall/whiteboard.
- Online participants: The User Story Map you will be using can be found in the Miro board “Agile Training for dRTPs”.
- Scrum Masters: Ensure that all members of the team are involved.
3.2.3. Prioritisation of User Stories & Release Planning
So far we have created our User Story Map and identified our User Activities, Epics, and User Stories. In this section, we will learn:
- how to prioritise our User Stories,
- create a release plan,
- and plan our first release, also known as the MVP.
To support this, we use Swimlanes. Swimlanes are horizontal bands that represent planned product releases or iterations. They allow us to visually organise the backlog and decide what to build first. By slicing the story map into swimlanes, we can separate the MVP features from those that can be delivered in later releases.
i. Prioritise stories using MoSCoW
In order to identify which stories are most important and should be worked on first, we will prioritise them using MoSCoW labels.
- M (Must-have): These are the requirements needed for the project’s success.
- S (Should-have): These are important requirements for the project but not necessary.
- C (Could-have): These requirements are “nice to have”, but don’t have as much impact as the others.
- W (Won’t-have this time): These requirements aren’t a priority for the project.
Example: User Stories with MoSCoW labels for ‘Rental Booking’ product
ii. Organise User Stories from Top to Bottom
After prioritisng we will arrange the MoSCoW categories into swimlanes so each release delivers cohesive user value. The highest priority (Must-have labelled) stories will go into top lane.
- M (Must-have): Essential stories go in top swimlane.
- S (Should-have): Important stories go into next release.
- C (Could-have): Nice-to-have stories for future iterations go into lower swimlanes.
- W (Won’t-have this time): Out of scope for now, but may be revisited later
Example: Organised User Stories with MoSCoW labels for ‘Rental Booking product’
iii. Plan Release
Now that we’ve prioritised our stories and organised them into swimlanes, the next step is to think about how we release value to our users. Release planning is not only about finding the MVP — it’s about shaping a roadmap of incremental deliveries that keep adding value over time.
We’ll start by defining the MVP, which is the smallest set of stories that deliver the most critical functionality for our users. From there, we can layer in additional releases, each building on the last.
When planning releases, keep in mind:
- Focus on the minimum set of stories that deliver meaningful value
early.
- Balance ambitions with available resources — aim for the smallest
amount of work that still feels like a real product.
- Remember that later releases should expand the product in ways that deepen value for users and broaden adoption.
In short, release planning helps us make tough choices about what to deliver first, what to deliver next, and what can wait — ensuring the product grows in a way that’s both sustainable and valuable.
Example: Release plan for ‘Rental Booking’ product
By combining swimlanes with MoSCoW prioritisation, you can clearly see what to build first (MVP), what comes next, and what can be deferred. By structuring your story map into swimlanes, you can better align development to your product roadmap.
Challenge 4: Prioritise User Stories and Plan First Release/MVP for Your Top-Priority Persona (10 minutes)
In your teams, take on the P.O. role and:
- Prioritise User Stories with MoSCoW labels
- Organise the MoSCoW-labelled stories into horizontal swimlanes
- Plan the First Release / MVP
- Reprioritise as Needed (Adjust stories between swimlanes if necessary to ensure the first release delivers maximum user value)
- After planning the first release (MVP), take only the User Stories
included in the MVP and add details to them:
- Add Description, ensure each story clearly captures the who, what, and why from the user’s perspective.
- Add Acceptance Criteria using Gherkin syntax, as demonstrated in Section 2.1.1.4.
Note: Remember that at this stage, we are only detailing the User Stories included in the MVP, since these are the stories that will be worked on in the first sprint. Detailing all stories at once is unnecessary, as lower-priority stories will be refined later when they become relevant.
Further Instructions
- In-person participants: Use duct tape or markers on the wall/board
to divide the sections to separate your releases.
- Online participants: Use lists or labels on the Miro board to organise stories into releases.
- Scrum Masters: Ensure that all members of the team are involved.
Readiness for the First Sprint Planning
By the end of this session, your team has created a ready Product Backlog as a User Story Map for the first sprint — you have prioritised the top-priority stories, written them clearly, with a description and acceptance criteria, making them ready for the first Sprint Planning.
In Scrum, this preparation step is known as Backlog Refinement — a collaborative activity where the team reviews and clarifies backlog items to ensure they’re ready for Sprint Planning. You’ll learn more about this ongoing practice in a later chapter, but for now, what you’ve done here in Challenge 4 serves as your first refinement session, ensuring the team can smoothly conduct Sprint Planning, where effort is estimated, the sprint goal is defined, and work for Sprint 1 is selected.
During this lesson, you focused on discovering user journeys, planning releases, and defining the MVP for the top-priority persona — the smallest set of features that delivers real, usable, end-to-end value to that key user. Focusing on one user at a time allows you to deliver core functionality quickly, test assumptions, and ensure the product works fully for that user before expanding to support additional users.
In real-world projects, teams rarely have unlimited time, budget, or resources to satisfy every user at once. By concentrating on the top-priority persona, you learn how to make strategic decisions under constraints, ensuring limited effort delivers the most value and insight.
In the upcoming lessons, you may extend value to additional essential personas identified in Challenge 2. This ensures the product evolves into a balanced, ecosystem-ready solution that supports all critical users.
In short, release planning helps you make tough choices about what to deliver first, what to deliver next, and what can wait — ensuring the product grows in a sustainable and valuable way.
- The Product Vision forms the basis for understanding the product’s purpose, value, and end users.
- User Story Mapping (USM) breaks down the product vision into User Activities, Epics, and User Stories, forming the basis of the Product Backlog.
- Epics are large bodies of work that take multiple sprints to complete.
- User Stories capture features from the user’s perspective.
- MoSCoW prioritisation and Swimlanes guide backlog organisation and MVP planning.
- The Product Owner leads backlog creation with team collaboration to plan incremental releases.
Content from Sprint Planning
Last updated on 2026-10-14 | Edit this page
Overview
Questions
- How to prepare for Sprint Planning meetings?
- How to conduct Sprint Planning meetings?
- How is the Sprint Backlog created?
Objectives
By the end of this chapter, you will be able to:
- Understand the purpose and structure of a Sprint Planning meeting in Scrum.
- Understand and define clear Definition of Done (DoD).
- Define a clear and achievable Sprint Goal using the SMART criteria.
- Identify candidate backlog items that align with the Sprint Goal.
- Estimate Story Points for each user story using Planning Poker.
- Validate the Sprint Goal and sprint scope based on effort estimates.
- Create a Sprint Backlog and commit to the sprint, including Stroies and priorities.
- Collaborate effectively as a Scrum Team to plan and commit to a realistic sprint.
4.1. Introduction
To recap from previous Chapters, you’ve learned how to move from the Product Discovery phase to defining and organising stakeholder needs through the Product Backlog. You worked with the Product Owner (P.O.) to translate these insights into clear, prioritised User Stories. Through Backlog Refinement, you developed these stories further by breaking down large Epics into smaller actionable items, adding descriptions and acceptance criteria, and ensuring each story aligns with business value.
Now, it’s time to move forward. In this next chapter, you’ll learn how to take that refined Product Backlog and plan your Sprint. In Scrum, a sprint is a short, time-boxed period during which the Scrum Team works to complete a set of product backlog items. Sprints typically last two to four weeks.
Sprint planning is a Scrum event held at the beginning of a sprint to set expectations for upcoming work. The team collaborates to define sprint goals, determine what work can be accomplished within the sprint, and outline the steps for completing the necessary tasks.
The key participants of the Sprint planning meetings are the P.O., the Development Team and the Scrum Master.
- The P.O. defines the sprint goal (we will cover it in detail in the section below) based on the value that they seek and what backlog items contribute to that goal.
- The Development Team needs to understand how they can or can’t deliver that goal.
- The Scrum Master chairs the meeting, ensuring that the planning process is followed and that everybody participates and understands.
Sprint planning should be constrained to no more than two hours for each week of the sprint. So, for example, the sprint planning meeting for a two-week sprint would be no longer than four hours.
Here is a reminder of the slide that visualises the Sprint Planning meeting. 
Image Source: Agile Methods for
RSE
The input to the Sprint Planning is the refined Product Backlog.
The outcome of the Sprint Planning is a Sprint Backlog, created after the team agrees on a clear Sprint Goal and understands how they will work toward it.
4.2. Prepare for the Sprint Planning Meeting
Note: If you are about to plan your first sprint, you can skip Section 4.2 and head straight to Section 4.3.
Before you jump into Sprint Planning, take a moment to remember the lessons from your last sprint. The improvements your team identified during the Sprint Retrospective Meeting should guide how you plan and work in the new sprint. This helps you avoid repeating old mistakes and encourages continuous improvement.
Challenge 1: Review Retrospective Actions (1 minute)
- Look at your Retrospective Wall created at the end of the last sprint.
- Review the action plan so you remember what the team agreed to start, stop, and continue doing.
- Keep these actions in mind throughout the upcoming sprint and actively work on them as a team.
- Scrum Master: It is your responsibility to remind the team of these commitments and help ensure improvements to team dynamics, processes, and tools are followed through.
4.3. Conduct the Sprint Planning Meeting
In this section, we will take a closer look at the Sprint Planning process, how a Scrum team collaborates to plan a sprint, define what work will be done, and determine how it will be accomplished.
The main steps in the sprint planning meeting are:
- Define the Sprint Goal
- Identify candidate backlog items
- Estimate Effort / Story Points
- Create the Sprint Backlog & Commit for the Next Sprint
We will explore each of these activities in detail below, with hands-on exercises to practice and understand them. You will also see examples using the same “Rental Booking” product featured in Chapter 3 for demonstration purposes.
It is worth noting that:
- Steps 2, 3, and 4 in the Sprint Planning Process are iterative: after estimating effort, the team may need to adjust which backlog items are included.
- Sometimes iteration may loop back to Step 1 (Define the Sprint Goal) if major adjustments affect what can realistically be achieved.
- During the Sprint Planning session, the Sprint Goal is not fixed; it should be validated and updated if necessary, before the sprint begins.
Before we can decide what to plan for the sprint, there is one critical question the team must align on:
How will we know when work is truly finished?
Without a shared understanding of what “done” means, teams risk planning work that cannot realistically be completed within the sprint, underestimating effort, or disagreeing later on whether a user story is complete. This often leads to unfinished work, rework, and frustration during the Sprint Review.
To avoid this, Scrum teams establish a shared agreement called the Definition of Done (DoD) before committing to sprint work.
4.3.0. Definition of Done (DoD)
- The Definition of Done includes all of the characteristics and standards an Increment needs to meet in order to be released.
- The DoD should be inspected and adapted at the Sprint Retrospective.
How do you start the Definition of Done?
The DoD starts with organisational standards that all teams must follow as a minimum. That infers that teams can add to the organisational DoD but cannot omit items from it. If multiple teams work on one product, they comply with the same DoD, but each team might have additional items in their DoD.
Difference between DoD and Acceptance Criteria (AC)
- The DoD is a set of high-level criteria for determining if a product increment is complete. It applies to all product increments and defines the overall quality of a product.
- In contrast, acceptance criteria are low-level conditions that apply only to specific user stories or features. AC defines whether a user story is acceptable to a customer.
- Acceptance criteria are assigned to each Product Backlog Item (PBI).
- An example of DoD could be: “All documentation is written and updated.”
- An example of AC could be: “The link to the user documentation is accessible from the navigation menu.”
Note: For further details on DoD you can watch this Video
Challenge 2: Create Your Team’s Definition of Done (5 minutes)
Note: This Challenge only needs to be done in Sprint 1. For the rest of Sprints teams will be inspecting and adapting their DoD during the Sprint Retrospective.
- As a team, think about everything that must be completed for a product increment to be usable and valuable. Write each activity or condition on a separate sticky note and place them on the board.
- Group similar or duplicate items together.
- Discuss and clarify any items that are unclear or ambiguous.
- Ask: Is this required for every user story to be considered done?
- Agree as a team on which items should be included in your Definition
of Done.
- Remove items that describe how work is done (tasks) rather than when it is done.
- (Don’t throw these items away! They might be useful then defining Acceptance Criteria on upcoming tasks.)
- Take a team vote to confirm that everyone agrees with the Definition of Done.
4.3.1. Define the Sprint Goal
During sprint planning, teams can easily get stuck discussing small details, like which task to do first, who should do it, and how long it will take. That’s where the sprint goal helps.
A sprint goal explains the purpose of the sprint. It gives the team a shared objective and reminds everyone why the sprint is worth doing.
So far in this course, your goal has been to work toward a Minimum Viable Product (MVP) or first release. Remember that:
- You don’t have to finish all the MVP user stories in one sprint.
- A release can include multiple sprints, depending on how much work is needed.
Creating the sprint goal is the P.O.’s responsibility, but it should be done together with the whole Scrum Team, including the Development Team, Scrum Master, and Product Owner.
The concept of SMART plays an important role in setting sprint goals. SMART stands for
- Specific
- Measurable
- Achievable
- Relevant
- Time-bound
Following SMART ensures that you set attainable goals that provide measurable results and contribute to your larger organizational objectives.
You can see examples of sprint goals for the ‘Rental Booking’ product in the image below:
4.3.2. Identify Candidate Backlog Items
Once the Sprint Goal is clear, the next step is to identify the user stories that will help achieve it. The P.O. presents the high-priority items from the product backlog, and the team discusses which ones best support the Sprint Goal.
Examples of candidate backlog items for the Sprint Goals defined for the ‘Rental Booking’ product are shown in the image below:
Challenge 3: Define the Sprint Goal & Identify Candidate Backlog Items (5 minutes)
As a team, work with your P.O. to define a clear Sprint Goal.
Decide:
- What specific capability or outcome should be delivered by the end of this sprint?
- How will we measure whether the Sprint Goal has been achieved?
- Is the goal realistic given the sprint duration?
Identify Candidate Backlog Items:
- Review the product backlog and identify the user stories that will contribute to achieving the Sprint Goal.
- Discuss and agree on a shared Sprint Goal that everyone understands and supports.
Further Instructions:
- Scrum Masters: Ensure that all team members actively participate in the discussion.
- Make sure the Sprint Goal follows the SMART criteria described above in section 1.
- Online participants: Use the “sprint goal candidate” tag in the Miro board to mark the identified user stories.
4.3.3. Estimate Stories with relative Story Points
Sprint planning requires some level of estimation. A Story Point is a number that represents:
- Volume: How much there is
- Complexity: How difficult it is
- Knowledge: What we know
- Uncertainty: What’s not known
Story points are relative, and are not connected to any specific unit of measure.
Planning Poker is a game used to obtain a consensus on how long each User Story will take to complete. Each team member has a set of poker cards with a time estimation written on the back (e.g., ‘don’t know’, ‘infinity’, 0, ½, 1, 3, 5, 10, 13, 20, 50, 100’). In this scale, smaller numbers (e.g., 1) indicate that the story will take less effort, while larger numbers (e.g., 20 or 50) indicate that the story will take more effort.
A team can only make estimations based on what they have learnt so far. As more sprints are completed, the team’s ability to predict and reach a consensus on how long tasks will take will improve.
To play Planning Poker, the following steps are repeated for each User Story that could contribute towards the Sprint Goal:
- Each player estimates the relative effort required for the User Story and plays the respective card face-down, so nobody can see.
- When every player has played a card, they are all turned over simultaneously and the answers compared. Team members are invited to explain why they chose their estimates, particularly those with very different answers to the rest of the team.
- Steps 1 and 2 may be repeated until a consensus is reached amongst the whole team.
- The agreed estimate (in story points) is added to the User Story.
Important things about Story Points
- Story points measure volume, complexity, knowledge, and uncertainty, not exact hours or days.
- Estimates are relative — compare all stories to the smallest story in the list, not to a fixed time.
- Example: If Story B is roughly twice as complex as Story A, it gets about twice the points.
- Story points help teams plan, address uncertainty or risk, and commit to achievable work, without bias or emotional attachment.
- Story points reward team members for solving problems based on multiple measurements, not simply time spent.
Challenge 4: Estimate Stories with relative Story Points (10 minutes)
As a team, estimate the effort required for the selected candidate user stories in relation to your Sprint Goal from Challenge 3 above.
Decide
- Evaluate each story for how much work there is (volume), how difficult it is (complexity), how familiar the team is with the work (knowledge), and what is unknown or risky (uncertainty).
- Use Planning Poker to estimate story points relatively, by comparing each story to the smallest or simplest story (ideally, start with a simpler story first so this measure can be approximated).
- Reach a team consensus on each story’s estimate.
- Estimates should assume that each story meets the agreed Definition of Done (DoD).
Follow the steps of the Planning Poker game outlined above (1–4).
Further Instructions:
- Online participants: Use the Planning Poker tool on the Miro board to do this (instructions for how to play are on the board itself).
- If a consensus cannot be reached after a few rounds, set the story aside and create a secondary task to clarify it later.
- Scrum Masters: Ensure all team members participate, explain their reasoning, identify any risks that could make the story complex, and work toward a collaborative decision after listening to everyone.
Challenge 5: Validate Sprint Goal & Sprint Scope (5 minutes)
As a team, review the Sprint Goal and the identified backlog items against the Sprint Goal in light of your effort estimates.
Decide:
- Based on your estimates, can all the identified items/User Stories realistically be completed within the sprint duration?
- Can all selected stories realistically meet the Definition of Done (DoD) within this sprint?
- If the sprint seems overloaded, discuss and negotiate with the P.O.
to:
- Remove or defer some backlog items
- Adjust the Sprint Goal if necessary
Further Instructions:
- Scrum Masters: Facilitate the discussion to ensure everyone participates.
- Focus on achieving a realistic, committed plan rather than trying to fit everything in.
4.3.4. Create Sprint Backlog & Commit for the Next Sprint
The Sprint Backlog is the set of user stories that the team commits to completing in the upcoming sprint and it includes:
- The user stories or product backlog items selected to achieve the Sprint Goal.
- The effort estimates and priorities agreed on by the team.
The process so far in defining the Sprint Goal, selecting candidate backlog items, estimating effort, and validating scope has laid the foundation for creating a realistic, actionable sprint backlog.
Referring back to the introductory presentation, we can see that we now have the information required to create the Kanban style sprint backlog, as shown below:
Image Source: Agile Methods for
RSE
Challenge 6: Create the Sprint Backlog & Commit for the Next Sprint (5 minutes)
Now that the Sprint Goal is validated and effort estimates are known, it’s time to create your Kanban-style Sprint Backlog.
- On a whiteboard or Flip chart (physical or digital), create four columns: To Do, In Progress, Blocked, Done.
- Move all user stories and tasks that were selected to go into the Sprint Backlog, into the To Do column.
- As the sprint progresses (in the following episode), team members will move tasks from To Do → In Progress → Done or Blocked if required.
Further Instructions:
- Scrum Masters: Ensure all team members agree on the stories in the Sprint Backlog and understand each one.
- Online participants: Use the relevant Kanban board in the Miro board for the current Sprint; remember that (1) you can duplicate elements from the User Story Map into the Kanban board (but not vice versa), and (2) you need to sync any changes following the duplication manually between the Kanban board and the User Story Map.
Image Source: Agile Methods for
RSE
- At the start of each sprint, there is a Sprint Planning Meeting
- The Sprint Planning Meeting is attended by the Scrum Team: The Product Owner, Scrum Master and Development Team
- The Product Owner ensures that the highest priority User Stories are highlighted.
- The definition of done (DoD) is a shared set of criteria that determines when a product increment is complete and ready for release.
- A clear DoD ensures quality, minimizes rework, and aligns team members on expectations for completion.
- DoD should be collaboratively defined, visible, and regularly updated as the team learns and evolves.
- The Development Team add a story point estimate for each User Story. One way to do this is by playing Planning Poker.
- The Development Team collectively decide on which User Stories will go into the upcoming Sprint and agree to a Sprint Goal, thus creating a Kanban style Sprint Backlog.
Content from Sprint Development Work
Last updated on 2026-10-14 | Edit this page
Overview
Questions
- How do Developers select, manage, and progress User Stories during a Sprint?
- How can teams improve collaboration using agreed ways of working?
Objectives
- Understand how Sprint Development work is organised and managed using the Sprint Backlog and Kanban board.
- Learn how to manage blocked work effectively.
- Explore collaborative ways of working and apply improvements from the Sprint Retrospective.
5.1. Introduction
During the Sprint Development period, you will complete the work required to finish the Sprint Backlog Stories selected for the current Sprint, in order to achieve the Sprint Goal.
5.2. Selecting User Stories
During the Sprint, participants working in Development roles (this may also include the Scrum Master and/or Product Owner in this course) will select Stories from the Sprint Backlog to work on.
Once a Story is selected:
- The Developer must assign the Story to themselves.
- Move the Story from the “To Do” column to the “Doing” column on the Kanban board.
5.2.1. How many Stories can I put into “In Progress”?
In Agile, a WIP (Work-In-Progress) limit controls how many tasks can be worked on at the same time in each stage of the workflow. WIP limits help by:
- Reducing multitasking and context switching between tasks
- Highlighting bottlenecks where work is getting stuck
- Improving workflow, so tasks are completed faster
In this course, your sprint backlog acts as a Kanban board with the following workflow (columns): To Do, Doing, Blocked, and Done.
Note:
While this course uses a fixed Kanban workflow, real-world teams often adapt their Kanban boards to suit their own objectives.
A good starting point for teams is to set the WIP limit equal to the number of people working. For example, if three people are working on the project, only three Stories should be in the “Doing” column at any time. A new Story can be moved into “Doing” only when there are fewer than three Stories already there.
Similarly for a single person working on a project, a good starting point is to allow only one Story in the “Doing” column by setting its WIP limit to 1. This helps maintain focus, efficiency, and adaptability.
Extra Reading: If you are interested in learning more about WIP limits and related concepts, you can refer to The Kanban Guide for Scrum Teams after the course.
5.2.2. Handling Blocked Stories
If a Story becomes blocked because the assigned owner (of the Story) is waiting on something:
- Move the Story to the “Blocked” column on the Kanban board.
- This indicates that the Story is no longer being actively worked on.
- The developer then picks up another story from the “To Do” column and moves it to the “Doing” column on the Kanban board (note that this should not exceed the WIP limit).
Good practice:
- Add a comment explaining why the Story is blocked.
- Link any related Stories where relevant.
Challenge 1: Select a Story to work on (10 minutes)
- As a Team set WIP limit for “Doing” column (one Story per Developer).
- Each participant working in the Developer role should select a Story they want to work on from the Sprint Backlog.
- Assign the Story to yourself by writing your name on it.
- Move the Story from the “To Do” column to the “Doing” column on the Kanban board (Keep in mind WIP limit for “Doing” column).
- When work is complete, move the Story from the “Doing” column to the “Done” column on the Kanban Board.
Important: An item can only be marked as “Done” and moved to the “Done” column once it meets the team’s Definition of Done (DoD). Before moving it to “Done” column, ensure that all criteria in the DoD have been satisfied.
Ways of Working
You may decide as a team how you want to work on the Stories, but your approach should encourage team collaboration.
A few options include:
- Team members working individually as developers on separate Stories.
- Dividing roles (for example: one designer, one or two developers/builders, one tester, etc.).
- Using an Agile pair-programming approach,
where:
- One person does the programming (in this course, the building/development).
- Another reviews it to ensure it meets the acceptance criteria.
- (Reminder: You are not doing any programming in this course, but you can follow the approach in this course to improve collaboration.)
Further Instructions
Online Participants
- As you are using Minecraft, you can not start working on your Stories until all team members have gathered in the valley.
- Once everyone is together in the same place then you can start working on your Stories.
- If a team member is lost:
- Brainstorm as a team and come up with a strategy to find them in the valley.
Team Collaboration and Improvement
- Consider what you discovered during the Sprint Retrospective (if this is not your first Sprint).
- Reflect on team dynamics and any challenges identified.
- Implement the agreed improvements and new ways of working during this challenge to improve collaboration if required.
- Developers select Stories from the Sprint Backlog to work on during the Sprint Development, in order to achieve the Sprint Goal.
- Work is managed using the Kanban board by assigning Stories and moving them across columns.
- Blocked Stories must be moved to the “Blocked” column, with clear comments explaining the issue, to allow Developers to pick up other work.
- Teams agree on ways of working that encourage collaboration and apply improvements identified during the Sprint Retrospective.
- The Scrum Master ensures the team follows the agreed process, manages time, and supports effective collaboration.
Content from Sprint Review
Last updated on 2026-10-14 | Edit this page
Overview
Questions
- How do we conduct Sprint Review meetings?
- What does this meeting achieve?
Objectives
- Use Sprint Review meetings to demonstrate the Sprint Increment to the Stakeholders.
- Evaluate the Sprint Goal progress and alignment with the Product Vision.
- Celebrate achievements and identify improvements.
6.1. Introduction
In this episode, you will learn how to prepare for and conduct a Sprint Review Meeting.
6.2. Sprint Review Meeting
A sprint review meeting is a fundamental ceremony in Agile development, specifically within the Scrum framework. It marks the end of a sprint, during which the development team delivers a potentially shippable increment of product functionality.
In a sprint review, the Scrum Team and stakeholders gather to review and demonstrate the work completed during the sprint. This provides an opportunity to showcase the features developed, gather feedback, and ensure alignment with the product vision and requirements.
Important: Anyone can be the facilitator of the Sprint Review; they can be a member of the Scrum Team, one of the stakeholders, or someone not involved in the project at all. Often, the Product Owner (P.O.) facilitates the Sprint Review since they are the stakeholders’ representatives for the Scrum Team during the Sprint and they are often best at speaking the customer’s language.
6.3. Conduct a Sprint Review Meeting
Before conducting a sprint review meeting, you need to plan the review in advance. For example, decide which items will be reviewed and discussed.
Remember: only work that has met the “Definition of Done” can be included in the sprint review.
Challenge 1: Prepare for a Sprint Review Meeting (4 minutes)
In your teams,
-
Review the Sprint Backlog
- Look at all stories or features completed during the sprint.
- Identify which ones meet the “Definition of Done” and are ready for review.
-
Select Stories for the Review
- Choose stories to showcase in the meeting.
-
Plan the Demo Sequence
- Decide the order in which stories will be presented.
- Assign team members to demonstrate each story.
Now that you have planned your sprint review meeting, the next step is to understand the key activities involved. A typical sprint review includes:
- Demonstration of completed work
- Feedback collection
- Alignment with the product vision
- Celebration of achievements
- Identification of improvements
We will explore each of these steps in detail and guide you through practical exercises where necessary to experience the sprint review process firsthand.
6.3.1. Demonstration of Completed Work
The development team demonstrates the features completed during the sprint to key stakeholders, including the product owner, customers, and other relevant parties.
6.3.2. Feedback Collection
Stakeholders provide feedback on the demonstrated features, enabling the team to adjust and prioritise work effectively in subsequent sprints.
Challenge 2: Demo & Feedback Collection (5 minutes)
Note: Entire team, you are in the Sprint Review Meeting now!
Step 1: Demonstrate Completed Work
Present the increment built during the sprint.
-
For each story in the sprint backlog:
- State the sprint goal it
fulfils
- Demonstrate the designed features
- Refer to the existing acceptance criteria from the backlog to show how the story is done
- State the sprint goal it
fulfils
Step 2: Verify, Collect, and Process Feedback
-
Stakeholders (Product Owner in this training) check whether the work presented for each story meets the story’s acceptance criteria:
- All criteria met → success confirmed
- Some criteria not met → note bugs
- New ideas or enhancements
- All criteria met → success confirmed
The team records any bugs or enhancements on Post-its.
Enhancements are added directly to the Product Backlog (User Story Map).
-
Bugs are handled as follows:
- If the bug arises because the story did not meet its acceptance
criteria, write it on the same Post-it if there is space, or use a new
Post-it attached to the original story, labeled as “bug” and move the
story back to the Product Backlog.
- If the story met its acceptance criteria, but a new bug is discovered, the story can still be marked as done. The bug should be added as a separate item in the Product Backlog for prioritisation during backlog refinement by the Product Owner.
- If the bug arises because the story did not meet its acceptance
criteria, write it on the same Post-it if there is space, or use a new
Post-it attached to the original story, labeled as “bug” and move the
story back to the Product Backlog.
See the example scenarios demonstrated in figures given below for both types of bugs.
Important: Do not prioritise or plan work on bugs or enhancements in the sprint review; this happens during backlog refinement.
6.3.3. Revisit the Sprint Goal and Check the Alignment of the Completed Work With the Product Vision
During the Sprint Review, the Scrum Team and stakeholders take a close look at how much progress was made toward the sprint goal. They also check whether the work completed fits with the overall product vision. This helps make sure the team is on the right track and that what’s being built is moving the product in the right direction.
Challenge 3: Evaluate the sprint goal progress and alignment with product vision. (3 minutes)
Instructions:
Review all completed stories in the sprint review.
-
Decide the overall sprint goal status:
- Fully achieved: All stories related to the sprint goal are complete and meet their acceptance criteria.
- Partially achieved: Some stories are complete, but one or more stories related to the sprint goal are incomplete or have unresolved bugs.
- Not achieved: Most or all stories for the sprint goal are incomplete or fail to meet acceptance criteria.
Check if the completed work supports the product vision.
Note down any gaps for discussion related to product or process.
Scrum Master: - Ensure product-related gaps are discussed in the Sprint Review meeting, as a part of this Challenge. Note that process-related gaps should be saved for the Sprint Retrospective meeting.
6.3.4. Celebration of Achievements
This provides an opportunity to celebrate the development team’s accomplishments and acknowledge their hard work and dedication.
CHALLENGE 4: Spotlight Moment (2 minutes)
Each team member, starting with the Scrum Master, should point out one thing another team member did that they found impressive, whether it’s a task, a contribution, or positive behaviour.
Rules:
- You only appreciate someone else
- Be specific. Here are some examples:
Task-based recognition
- “I appreciate how Alex designed the door hinge to reduce friction.”
Behavior-based recognition (listening, empathy, collaboration, support)
- “I appreciate how Adina checked in with teammates regularly to see if anyone needed support.”
- “I appreciate how Ann listened carefully to my concerns and asked thoughtful questions before suggesting a solution.”
- “I appreciate how David encouraged quieter team members to share their ideas in the meeting.”
- Avoid vague phrases like: “Good job, Alex.”
Scrum Master:
- Facilitates the appreciation round.
- Models the behavior by giving an example first.
- Ensures recognitions are specific and meaningful.
- Encourages visibility for silent or behind-the-scenes contributions.
- Helps the team practice consistent individual acknowledgment.
Missed a Recognition?
If this is your first sprint and you didn’t spot someone to recognise, don’t worry!
Pay attention during the upcoming sprint. Notice positive contributions, helpful behaviors, or tasks as they happen, so you can share your appreciation in the next Spotlight Moment 😊
6.3.5. Identification of Improvements
Through discussions and observations during the sprint review, areas for improvement in the development process can be identified and addressed in future iterations. These can then be shared in a future Sprint Retrospective.
In short, the sprint review promotes collaboration, transparency, and continuous improvement within the Agile development framework. It fosters a culture of open communication, collaborative working sessions, and shared responsibility for the product’s success.
- Sprint Review Meetings give the Scrum Team the chance to demonstrate the latest Product Increment.
- They are useful for checking the product is meeting the current requirements and to assist with refining the Backlog.
Content from Sprint Retrospective
Last updated on 2026-10-14 | Edit this page
Overview
Questions
- How do we conduct Sprint Retrospective meetings?
- What does this meeting achieve for the team and the Scrum
process?
- How can previous retrospective actions and Sprint Velocity inform future sprints?
Objectives
- Demonstrate how positive and negative retrospective feedback can be used to improve the Scrum process.
- Learn how to review previous action items and create actionable
plans for continuous improvement.
7.1. Introduction
In this episode, you will learn how to prepare for and conduct a Sprint Retrospective Meeting, in order to improve the processes in future Sprints.
7.2. Sprint Retrospective Meeting
Sprint retrospectives are regular meetings that take place at the end of every sprint.
Their purpose is to help the team reflect, learn, and continuously improve.
A retrospective aims to:
- Evaluate how the previous sprint iteration or work item went — focusing on team dynamics, processes, tools, and their Definition of Done (DoD).
- Identify, articulate, and prioritise what went well and what didn’t.
- Create and implement a plan for improving the way the team works.
Important: Every team member should attend the retrospective, with a member of the team leading the discussion. This member can be the scrum master, product owner, or it can rotate throughout the team.
Benefits of sprint retrospectives
Achieve continuous improvement: Building an action plan and following up on it in future meetings is critical for growth.
Improve team reflexivity: Reflexivity is the extent to which team members collectively reflect upon the team’s objectives, strategies, and processes and adapt them to current or anticipated circumstances.
Tips for Scrum Masters
Encourage the team to regularly review their capacity at the end of each sprint. Understanding how much work was realistically completed helps teams set achievable goals and forecast future progress.
Introduce Sprint Velocity as a supportive metric. Sprint Velocity reflects the amount of work the team completed during the sprint and can help guide future sprint planning — not as a performance measure, but as a signal for improvement and predictability.
-
When planning upcoming sprints, the team should consider the average velocity from previous sprints along with other factors such as holidays, technical challenges, or external dependencies.
For example: If the team’s average velocity is 15 story points and there are no expected blockers, the team may commit to user stories totaling around 15 points for the next sprint.
In the sprint retrospective meeting, use velocity trends to identify what supported or slowed the team’s progress. This can highlight systemic issues, process improvements, or opportunities for better collaboration.
Image Source: Agile Methods for
RSE
Challenge 1: Review Previous Retrospective Actions (2 minutes)
IMPORTANT: Skip this challnege if you are in the first sprint.
Before jumping into the retrospective meeting for the latest sprint, the Scrum Master should lead a short review of the action items agreed during the previous sprint retrospective.
Step 1. Display the previous retrospective’s action list (from the “What changes can we make?” column).
Step 2. Review each action item briefly, confirming:
- Whether it has been completed
- Whether it is still in progress
- Whether it requires further discussion or new actions
Step 3. Celebrate completed actions and acknowledge improvements achieved.
Step 4. Highlight any actions that were not completed and discuss whether they should:
- Be carried forward
- Be re-defined
- Be dropped if no longer relevant
Step 5. Carry any outstanding items into the new retrospective only if the team agrees they remain valuable.
Challenge 2: Conduct a Sprint Retrospective (6 minutes)
Scrum Master: Facilitate the Session
Step 1. Set Up the Retrospective Wall
Prepare a Retrospective Wall, clearly labelled with the sprint name and three columns:
- What went well?
- What went wrong?
- What changes can we make? (Actions)
Tip: Don’t forget to reflect on your Definition of Done (DoD). Did our DoD help us deliver a usable increment? If you learned something new, you can update the DoD during this Challenge.
Note: Online participants: use the Sprint Retrospective Area on the Miro board. In-person teams: use the physical board/wall provided.
Step 2. Gather Input from Team Members
- Ask each team member to write their thoughts on Post-it notes (in
person) or into an element on the retro board (online) in response to
the first 2 questions above.
- They should place each note under the appropriate column.
Step 3. Cluster Similar Ideas
- As a team, group similar notes together to create clear themes. (This helps focus the conversation and reduces duplication)
Step 4. Vote on Key Issues (Under “What went wrong?”)
- All participants vote on the notes in the “What went wrong?” column that they believe represent the biggest risks, blockers, or issues affecting team progress.
Step 5. Discuss the Top Issues
Identify the top two items with the most votes and discuss each one, focusing on:
- Why it happened
- How it affected the sprint
- What the team can do differently next time
Note: Keep the discussion solution-focused and time-boxed.
Step 6. Select Key Actions and Create an Action Plan
- Agree on clear and achievable action items that address the top
issues.
- Add these to the “What changes can we make?” column and assign an owner for each.
Note: If no owner is assigned, the Scrum Master will take responsibility for ensuring the action is followed up.
Further Guidance for Scrum Masters
- Ensure every team member participates and has the opportunity to
contribute.
- Prevent any individual from dominating the conversation — all voices
should be heard equally.
- Manage time carefully for each activity and steer the discussion
back on track if it begins to drift.
- Encourage a psychologically safe environment where honest reflection is welcomed.
Review of Action Items
- The Scrum Master will review the actions at the next Sprint Planning meeting to keep all action items visible during that session and to ensure they are addressed.
- These actions should also be reviewed at the start of the next
retrospective meeting to confirm what has been completed and what still
needs attention.
- The Scrum Master is responsible for ensuring that priority items are progressed and ideally completed by the time the next retrospective is held.
- Sprint Retrospectives provide a structured opportunity for the team
to reflect, learn, and improve processes.
- Reviewing past action items ensures continuity, accountability, and
progress before planning the next sprint.
- Sprint Velocity is a supportive metric for planning achievable
workloads and identifying trends in team performance.
- Effective retrospectives rely on facilitation, collaboration, prioritisation, and psychological safety to encourage honest reflection.
Content from Backlog Refinement
Last updated on 2026-10-14 | Edit this page
Overview
Questions
- How do we refine the backlog?
Objectives
- Be able to add new user stories, based on changes in requirements and priorities from the Product Owner and Stakeholders.
8.1. Introduction
To recap from our first sprint, you’ve learned that the Product Owner (P.O.) represents the needs of the stakeholders and is responsible for creating and maintaining the Product Backlog. The P.O. defines the end-user requirements and works with the Development Team and Scrum Master to help capture these requirements as User Stories, prioritise and detail them, and break larger stories (Epics) into smaller actionable User Stories. This process of prioritising, detailing, and preparing User Stories for upcoming sprints is called Backlog Refinement.
During the Product Discovery phase, you already practised a form of backlog refinement (recap): you prioritised the top-priority MVP stories, wrote them clearly with descriptions and acceptance criteria, and made them ready for the first Sprint Planning. In this lesson, we will build on that knowledge and prepare for the next Sprint Planning meeting.
Agile ways of working encourage a mindset where change is expected and embraced. Backlog refinement is an ongoing activity to ensure the backlog stays relevant, prioritised, and ready for upcoming sprints.
Typically, backlog refinement takes place before each Sprint Planning meeting, often every two weeks, and lasts around 30 minutes. The P.O. may also refine the backlog at any time — for example, when new feedback comes in from customers or other stakeholders within the business.
The main goals of backlog refinement are to help you:
- Keep the product backlog prioritised so the most important items are at the top.
- Break large stories into smaller, more manageable pieces.
- Ensure top-priority stories are clearly defined, with actionable acceptance criteria, and are ready for Sprint Planning.
Backlog refinement meetings are usually run by the P.O., with support from the Scrum Master and at least one member of the Development Team. Not every team member needs to attend, but it is important to have someone technical present — such as a lead developer or architect to provide input on technical feasibility and help ensure stories are well-defined and ready for development.
Challenge 1: Refine your Backlogs (5 minutes)
Goal: Ensure all current User Stories for existing personas are up-to-date, prioritised, and ready for Sprint Planning.
In your teams:
- Look through all existing User Stories in the product backlog (represented as a User Story Map) and see if you need to add any further ones based on what you now understand of the product, any challenges, or new requirements (e.g., clarifications or missing details in existing user journeys).
- Split large or unclear User Stories into smaller, actionable tasks.
- Make sure every User Story is correctly grouped under the right Epic.
- Reassess Priorities (Check whether priority levels need to change)
and update MoSCoW labels accordingly:
- This might be based on any User Stories that have been added.
- It may be based on things you learnt during the previous Sprint.
- It may be based on external factors or new risks that have been identified.
- For the top-priority User Stories, ensure details and acceptance criteria are added and clear.
Further Instructions
- Entire Team: engage with your P.O. to confirm any changes in priorities or new demands, and refine your work accordingly.
- Scrum Masters: ensure that all members of the team are involved.
Keep an eye on the MVP’s progress after each sprint
If the number of items is low and the team does not have enough work for the upcoming sprint, consider extending the scope by adding stories for another persona. Otherwise, this section (6.2. Extending MVP Value Across Users) given below can be skipped.
8.2. Extending MVP Value Across Users
Throughout this course, your goal has been to work toward a Minimum Viable Product (MVP), also referred to as the first release — the smallest version of the product that still delivers real, usable value.
As a recap from the Product Discovery chapter, you created your product backlog (as a User Story Map) and developed your first release plan focused on your top-priority user identified in Challenge 2: Ranking the User Types / Personas for the required Product. The purpose of this was to help you deliver real, end-to-end value for that single user, allowing you to test assumptions and ensure the product works fully for that user before expanding to others.
In real-world projects, teams rarely have unlimited time, budget, or resources to satisfy every user at once. Agile encourages you to make strategic choices — deciding which user’s needs will deliver the most value first. This approach helps you focus limited resources where they’ll have the greatest impact.
Now, you’ll revisit your MVP and learn how to extend its value to additional essential users. A fully functional MVP must include the minimum features required for all essential users to make the system work end-to-end.
For example, a Rental Booking product can’t operate with only the guest’s features — it must also include the host’s basic functionality to complete the booking process.
In this section, you’ll expand your Product Backlog (using your User Story Map) to cover the next-highest-priority user. This exercise will help your MVP evolve into a more balanced, ecosystem-ready product that supports all key personas, while continuing to deliver value incrementally.
Challenge 2: Extend and Refine Your Product Backlog and Release Plan for Other Personas (10 minutes)
In your teams:
-
Review MVP Coverage
- Ask: does the current MVP still support all essential users and complete the main user journeys?
- Identify any missing interactions or dependencies that would prevent the MVP from functioning end-to-end.
-
Decide Whether to Extend
- If gaps exist or priorities have shifted, move to the next-highest-priority user identified earlier in Challenge 2: Ranking the User Types / Personas for the required product (Product Discovery phase).
- Extend your User Story Map by adding this user’s activities, epics, and new user stories.
-
Prioritise New Stories
- Apply MoSCoW labels to all new stories, organise them from high priority (Must-have) to low priority (Won’t-have), and decide which stories belong in the MVP.
- For any stories added to the MVP, refine them by writing clear descriptions and acceptance criteria using the Gherkin syntax (Given / When / Then) (recap here) to prepare them for Sprint Planning.
Further Instructions
- Entire Team: engage with your Facilitator (acting Product Owner) throughout the activity
- Scrum Masters: ensure that all members of the team are involved
There are a number of terms used to mean Backlog Refinement.
Others are “Backlog Enhancement”, “Backlog Grooming” or “Backlog Pruning”.
Our Product Backlog is once more up to date with the latest set of requirements from the Stakeholder(s) broken down into User Stories. We are now ready to do the Sprint Planning meeting, where we will select the next subset of User Stories to go into the Sprint Backlog, and we can return to Chapter 4 to do this.
- Adding and prioritising User Stories is an ongoing task, known as Backlog Refinement. (AKA “Backlog Enhancement”, “Backlog Grooming” or “Backlog Pruning”.)
- The Backlog needs to be fully refined and up-to-date before each Sprint Planning session begins.
- The MVP should provide the minimum functionality needed to support all essential users, ensuring the product works as a complete system.
Content from References
Last updated on 2026-09-26 | Edit this page
The following resources were used for reference and inspiration in creating this course content.
- Agile Methods for RSE, designed and developed by Ann Gledson and Adrian Harwood. Available at: [private course material, RSE Department, RIT, University of Manchester].
- Atlassian Community – Understanding Structure of the User Story Map
- Avion – What is User Story Mapping?
- LEGO4Scrum – LEGO4Scrum
- Lego Scrum Game 2017, UTS Software Engineering
- Scrum.org – Product Backlog Refinement
- Atlassian – Sprint Planning
- Atlassian – Sprint Reviews
- Atlassian – Retrospectives
- Atlassian Team Playbook – Retrospective Guide
- Atlassian – Product Backlog
- Scrum.org – Definition of Done (DoD)
- Scrum.org – Sprint Retrospective Practices
- Carpentries Workbench Template