Key Points

Learning Objectives

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.

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.

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.

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.

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.

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.

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.