SCRUM basics
Julie Rudder & Claire Stewart
Outline
What is scrum (Claire)
Scrum roles (Claire)
Scrum rhythms and processes (Claire)
How to write stories (Julie)
How to decompose to tasks (Julie)
Rules! team pulls work, etc. (Julie)
What is Scrum?
•
•
•
•
Agile project management methodology
Focus on reducing complexity by breaking
down work
Short work cycles with frequent deliverables,
iteration
Emphasis on making work visible
Scrum roles
Product Owner
The person responsible for maintaining the Product Backlog by
representing the interests of the stakeholders. Drives work by writing
stories, and decides when they are done. Available to the team.
Scrum Master
The person responsible for ensuring the Scrum process is used properly
and facilitating resolution of issues raised by the Scrum Team. Does not
direct the Team, but facilitates their work.
Team
A cross-functional group of people responsible for managing itself to
develop the product. Breaks down Stories into Tasks & executes them.
Stakeholders
The people for whom projects are completed. They are directly involved
only during sprint reviews.
Source: http://www.mountaingoatsoftware.com/scrum-figures
Traditional components of Scrum
Component
Description
Sprint
Time-boxed work period to complete planned stories (2 weeks for us)
Stories
Projects that result in a discrete deliverable and can be completed within a
short time, hours or days
Tasks
Smaller increments of work; every story is broken down into tasks
Epics
Large initiatives that have multiple stories
Product Backlog
List of prioritized stories that have not been started
Sprint Backlog
Detailed list of stories for the current sprint
Sprint Planning
Full-team session to create tasks and effort for stories on the sprint backlog
and volunteer task ownership
Daily Scrums
Full-team updates on project progress
Sprint Retrospective
Full-team session to evaluate previous sprint’s success, both in deliverables
and in process.
Deliverables
Discrete work outputs – may be milestone or epic completion
The Board
Story Format
As a:
I want to:
So that:
Done looks like:
Story Format
As a: < from the user perspective >
I want to:
So that:
Done looks like:
Story Format
As a: < from the user perspective >
I want to: < in narrative form, briefly explain the feature>
So that:
Done looks like:
Story Format
As a: < from the user perspective >
I want to: < in narrative form, briefly explain the feature>
So that: < why is this feature important? >
Done looks like:
Story Format
As a: < from the user perspective >
I want to: < in narrative form, briefly explain the feature>
So that: < why is this feature important? >
Done looks like: < what is the acceptance criteria? >
How to write stories: Good stories
Stories are told from the perspective of the user.
Stories are understood by the team and can be broken into discrete tasks.
Stories contain work that are to be done by the team.
Stories are ready to be started.
Stories have acceptance/done criteria.
Bad story - too big
Bad example - too big
Better story
As a: System Administrator
I want to: easily integrate my campus authentication system with Curate.
So that: users at my institution can log in with their campus credentials.
Done looks like: Curate has a flexible authentication system that allows new
institutions to configure their campus preferred authentication system
without writing new code. Common systems are CAS, LDAP,
SHIBBOLETH, and more.
Sizing Stories
Assign a value to each story to measure COMPLEXITY
and SIZE of the story relative to you team.
Sizing helps us:
● locate unknowns in the work and add needed
information
● build team consensus of the work to be done
How to size
2 = very fast and easy to do in small
amount of time and effort
4
8
16
32 = too big, too unknown - needs to
be broken down into smaller stories
Most stories should be around
2 = very fast and easy to do in small
amount of time and effort
4
8
16
32 = Too big, too unknown - needs to
be broken down into smaller stories
If sizing is all over the place
If sizing is all over the place
Team members explain why they assigned
certain numbers.
If sizing is all over the place
Team members explain why they assigned
certain numbers.
Team comes to consensus about the size.
Decompose stories to tasks
Tasking is not a way of
accounting for time spent but a
way to keep atomic chunks of
work in front of people's eyes, so
that the team can see at a glance
what is available to do and what
may be blocked.
Rules!
Team driven work
Pull your own work (tasks)
Standups exist for the team - team members should address the team without
worry of being too technical, it’s not a report to POs
All team members required to attend stand up (of course you will be out
sometimes)
Show up on time, end on time
Make your work visible
Discussion, questions
It can take a little while to get used to Scrum!
What questions do you have?