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

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.

Callout

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.

Callout

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

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:

User Activities for Rental Booking product.

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

Activities, Epics, and User Stories for 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.

Callout

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:

Detailed User Stories for Rental Booking product.

Connecting user stories to the higher-level activities and epics on your map provides critical context.

Challenge

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

Prioritised 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

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.

Callout

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.

Callout

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.

Key Points

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.