Scrum is an agile framework for managing product development projects. It involves breaking work into small increments and using time-boxed iterations called sprints to structure development. Key roles include the product owner who manages requirements, the scrum master who facilitates the process, and the cross-functional development team. Scrum involves regular planning, daily stand-up, sprint review and retrospective meetings to coordinate work and continuously improve. Requirements are captured as prioritized user stories in a product backlog and delivered in sprints using a sprint backlog and definition of done.

1. Scrum Overview
Christopher Moss

2. Contents
• Introduction
• Scrum in a nutshell
• Benefits over Waterfall
• Roles
• Product Owner
• Scrum Master
• Development Team
• Scrum Ceremonies
• Sprint Planning
• Scrums
• Sprint Review
• Sprint Retrospective
2
• Scrum Artefacts
• Product Backlog
• User Stories
• Sprint Backlog
• Acceptance Criteria
• Definition of Done
• Glossary
• References & Recommended Reading

3. Introduction

4. Scrum in a nutshell
• Work is broken down into small tasks and ordered by value in a Product Backlog:
£
£
£
4

5. • Tasks are effort estimated and delivered in time boxed iterations called Sprints:
Sprint 1
Scrum in a nutshell
5
Sprint 2 Sprint 3 Sprint 4
January February March April

6. • Within each Sprint there are four key meetings, also known as ceremonies:
Scrum in a nutshell
6
Sprint 1
Sprint
Planning
Sprint
Retrospective
Sprint
Review
Scrums… …
Sprint 2
Sprint
Planning
…
Tasks are effort
estimated and
a suitable
number
selected that
can be
delivered in
one Sprint.
Scrums, also
known as
stand ups, are
daily short
meetings,
where the team
coordinates
their work.
Completed
work is
demonstrated
to business
stakeholders
and formally
accepted as
completed.
The team
reflects on how
well work was
completed and
come up with
ideas on how
to improve their
ways of
working in the
next Sprint.
Repeat…
1. 2. 3. 4.

7. • There are three key roles:
Scrum in a nutshell
Product Owner Scrum Master Development Team
A single individual who is
responsible for ordering
the Product Backlog.
Their focus is primarily
external to the team with
business stakeholders,
customers and end-users.
A single individual who
supports the Development
Team.
They help the team run the key
ceremonies and adhere to
Scrum principles to deliver
working functionality in each
time-boxed Sprint.
The cross-functional mix of
people who deliver the
required functionality, whether
developers, designers, testers
or business analysts etc.
They are self organising. They
decide how to deliver the work
themselves.
7

8. Benefits over Waterfall
Value
Value
Time
Time 8
Delivers value quicker
• Value to end-users is only delivered at the very end of Waterfall projects, whereas Scrum projects
deliver tangible value after every Sprint:
Waterfall
Scrum

9. Benefits over Waterfall
£
£
£
Improves responsiveness to change
• New requirements can be added as they emerge during the project.
• This can occur, for example, as business stakeholders have new
ideas, the technical team discover new issues or in reaction to
competitors and market conditions.
Reduces product risk
• Until functionality is released to end-users the understanding of
whether that functionality is valuable or not is an assumption.
• Scrum allows quick testing of assumptions on whether functionality
is truly valuable.
• It is better to find out that customers dislike a feature after a one
month Sprint than after 6 months of Waterfall development!
Improves quality and reduces technical risk
• Testing starts from the first Sprint, with regression testing throughout
the life of the project, which improves quality.
• This also mitigates the risk of issues being found late, common to
Waterfall projects where testing is at the end of the project, typically
when deadlines are looming and funding running low.
9
Emergent requirements can
be added to the Product
Backlog at any time

10. Scrum Roles

11. • There is only ever one Product Owner and one Product Backlog.
• The Product Owner is responsible for ordering the Product Backlog.
• They can be considered the “value maximiser”.
• Their focus is mainly outside the team with business stakeholders
and customers to build a deep understanding of their requirements,
with which they populate the Product Backlog.
• However, they should be available to the team to answer questions
and elaborate on requirements when required.
• They accept when requirements have been met by the team.
• They measure progress and forecast the project completion date.
Product Owner
11

12. • There is one Scrum Master per Scrum Team.
• They are responsible for ensuring the team follow the Scrum process
correctly.
• They manage the process rather than the team.
• A Scrum Master is not a boss. They do not direct a team like a
Project Manager, but rather facilitate the team’s meetings and help
them to self-organise and solve problems themselves.
• In this way, they are a servant-leader.
• They are responsible for removing impediments that block the team.
• They are also responsible for helping the parent organisation adopt
Scrum in addition to the team.
Scrum Master
12

13. • The Development Team is the cross-functional mix of people with all
the skills required to deliver the work.
• It can include, for example, developers, testers, designers, business
analysts, etc.
• The team is self-organising: they decide how best to complete work
themselves.
• The recommended team size is 3 to 9 people.
• It is recommended that members work full time on one project.
• It is better if the team members do not change, but if there are any
changes, it should be accepted that there will be a short-term
reduction in the team’s productivity.
• For larger projects, more scrum teams should be used rather than
increasing the size of one team.
Development Team
13

14. Scrum Ceremonies

15. Sprint Planning
15
Sprint 1
Sprint
Planning
Sprint
Retrospective
Sprint
Review
Scrums… …
Sprint 2
Sprint
Planning
…
• In this ceremony the team plans what it is going to deliver in the Sprint and how.
• This ceremony can last up to 8 hours for monthly Sprints and less for shorter Sprints.
• An overarching goal for the Sprint is set.
• The amount of effort required for each requirement (known as a User Story) at the top of the
Product Backlog is estimated.
• The team selects an appropriate number of User Stories to fill its capacity.
• User Stories are broken down into individual tasks on a Sprint Backlog.
• If the team is co-located, it is common for tasks to be written onto Post-it notes on a wall near the team.
• Other common tools for tracking Product Backlogs, Sprint Backlogs and Tasks are Trello and Jira.

16. Scrums
16
Sprint 1
Sprint
Planning
Sprint
Retrospective
Sprint
Review
Scrums… …
Sprint 2
Sprint
Planning
…
• In this ceremony the team coordinates their efforts and plans their work for the next 24 hours.
• The meeting should last no more than 15 minutes.
• It is common for co-located teams to stand by their Post-it notes to help keep the meeting short.
• The meeting should be held at the same time and place every day to reduce complexity.
• Each team member should answer:
1. What I accomplished since we last met
2. What I plan to do before the next scrum meeting
3. What obstacles are blocking me?

17. Scrums
17
Sprint 1
Sprint
Planning
Sprint
Retrospective
Sprint
Review
Scrums… …
Sprint 2
Sprint
Planning
…
• A burn-down chart can be used to visualise progress and forecast whether all tasks will be completed:
Tasks
Time

18. Sprint Review
18
Sprint 1
Sprint
Planning
Sprint
Retrospective
Sprint
Review
Scrums… …
Sprint 2
Sprint
Planning
…
• In this ceremony the team demonstrates the outcome of the sprint to the business stakeholders.
• This ceremony can last up to 4 hours for monthly Sprints and less for shorter Sprints.
• The aim is to collect feedback and requests for change from the stakeholders to ensure the project
is constantly adapting to their needs.
• The team collaborates to update the Product Backlog using this feedback.
• The Product Owner can use another burndown chart to forecast when the project will be complete.
Product
Backlog Items
Time

19. Sprint Retrospective
19
Sprint 1
Sprint
Planning
Sprint
Retrospective
Sprint
Review
Scrums… …
Sprint 2
Sprint
Planning
…
• In this ceremony the team reflects on how to improve the ways in which it works in the next sprint.
• This ceremony can last up to 3 hours for monthly Sprints and less for shorter Sprints.
• An example of how a retrospective can be run is to ask each team member:
1. What didn’t you like this Sprint? How could we improve on that?
2. What external factors stopped you from working in this sprint? How can we stop that?
3. What helped you in this sprint? How can we do more of that?

20. Scrum Artefacts

21. Product Backlog
• A Product Backlog is a prioritised list of requirements.
• It is not set in stone at the beginning of a project.
• New requirements can emerge as the project progresses. This can occur, for example, as business
stakeholders have new ideas, the technical team discover new issues or in reaction to competitors
and market conditions.
• The list is ordered by value: the most important items are always delivered first.
• It is the fuel that feeds the team.
• The Product Backlog replaces both Waterfall requirements documentation and Gantt charts.
• The Product Backlog is an information radiator; by looking at it any stakeholder can easily see what
is being worked on and what is planned.
21

22. • Requirements are specified in a Product Backlog as User Stories.
• The format is:
As a USER TYPE, I want GOAL, so that REASON.
• Example:
“As a premium subscriber, I want to receive ticket sale notifications earlier than free users,
to ensure I have the opportunity to buy tickets for events that will sell out quickly.”
• Reasons are used to aid prioritisation by value.
• The short format encourages discussion rather than detailed writing, which leads to a better shared
understanding by the team.
• Stories can be written by anyone in the team and should be:
Independent, Negotiable, Valuable, Estimable, Small and Testable.
User Stories
22

23. Product & Sprint Backlogs: Example
• An example of how Product and Sprint backlogs can be managed in Trello:
23
• The first list contains the full Product Backlog.
• The second list contains the Sprint Backlog; that is, the Stories committed to in the current Sprint.
• The third list is where completed Stories are moved to.

24. Product & Sprint Backlogs: Example
• An example of how User Stories can be broken down into tasks in Trello:
24
• A checklist of tasks can be added to each story card.
• In this example there are 4 tasks of which 1 has been completed.

25. Acceptance Criteria
• Each User Story should have acceptance criteria associated with it.
• These are conditions that need to be met for the User Story to be accepted as complete.
• They should be written in simple language, like the User Stories themselves.
• The following examples could be associated with a User Story to create a registration form
for new customers:
“The form will capture name, email address and postal address (optional).”
“The form cannot be submitted without all mandatory fields being completed.”
“The form will reject incorrectly formatted email addresses.”
“A welcome email will be sent to the user after submission.”
• Acceptance criteria remove ambiguity, help the team think from the user’s perspective and give a
basis for testing.
25

26. Definition of Done
26
• The Definition of Done is a list of criteria that ALL User Stories must meet to be accepted as complete.
• Acceptance Criteria are specific to a particular User Story, whereas the Definition of Done is general.
• It is defined and agreed to by the whole team, ensuring that everyone knows what “Done” means.
• Example criteria that could be included on a Definition of Done checklist:
Code complete
Unit tests passed
Integration tests passed
User acceptance testing passed
Production deployment complete

27. Glossary & References

28. Glossary
Burndown Chart - A chart showing effort remaining over time. Can help to make progress transparent.
Development Team - The cross functional mix of people with all the skills required to deliver the work.
Product Backlog - A prioritised list of requirements expressed as User Stories.
Product Owner - The individual responsible for maximising the value of the product being delivered.
Scrum Master - The individual who coaches the team & organisation to follow Scrum processes correctly.
Scrum Team - The Product Owner, Scrum Master & Development Team.
Sprint - A time-box within which all scrum ceremonies are contained.
Sprint Planning - The ceremony held at the beginning of a Sprint, where the Development Team select
their work for the upcoming Sprint.
Sprint Review - The ceremony held at the end of a Sprint, where work is demonstrated to stakeholders.
Sprint Retrospective - The ceremony held at the end of a Sprint, where the team reflects on how it can
improve its ways of working in the next Sprint.
User Story - A requirement specified in the format: “as a USER TYPE, I want GOAL, so that REASON.”
28

29. References & Recommended Reading
The Scrum Guide, Ken Schwaber & Jeff Sutherland
The core reference for Scrum theory.
Agile Project Management With Scrum, Ken Schwaber
A good introduction for new Scrum Masters.
Scrum Product Ownership, Robert Galen
A guide to the Product Owner role.
The Lean Startup, Eric Ries
How to maximise value and deliver what customers want. Not only relevant to startups!
User Stories Applied, Mike Cohn
How the Product Backlog is used to manage requirements, plan releases and track progress.
The Enterprise And Scrum, Ken Schwaber
Advice on adopting and scaling scrum within a large organisation with multiple scrum teams.
29

30. Christopher Moss
Delivery Consultant
chris@cjmoss.co.uk
07872995035
Scrum Overview Version 1.0 01-08-2016