1. Pick a Product Owner. This person is the onewith the vision of what
you are going to do, make, or accomplish. They takeinto account risks
and rewards, what is possible, what can be done, andwhat they are
passionate about.
2. Pick a Team. Who will be the people actuallydoing the work? This
team needs to have all the skillsneeded to take the Product Owners’
vision and make it a reality. Teamsshould be small, 3 to 9 people is
the rule of thumb.
3. Pick a Scrum Master. This is the person who willcoach the rest of
the team through the Scrumframework, and help the team eliminate
anything that is slowing them down.
4. Create and prioritize a Product Backlog. This isa list at a high level
of everything that needs to bebuilt or done to make that vision a
reality. This backlog exists andevolves over the lifetime of the
product; it is the product roadmap. At any point, the Product Backlog
is the single, definitive view of“everything that could be done by the
team ever, in order of priority.”Only a single Product Backlog exists;
this means the Product Owner isrequired to make prioritization
decisions across the entirespectrum. The Product Owner should
consult with all stakeholders andthe team to make sure they are
representing both what people wantand what can be built.
5. Refine and Estimate the Product Backlog. It iscrucial that the people
who are actually going to completethe items in the Product Backlog
estimate how much effort they willtake. The team should look at each
Backlog item, and see if it isactually doable. Is there enough
information to complete the item?Is it small enough to estimate? Is
there a Definition of Done, thatis, everyone agrees on what standards
must be met to call something“done”? Does it create visible value?
Each item must be able to be shown,to be demonstrated, hopefully to
be potentially shippable. Do notestimate the Backlog in hours,
because people are absolutelyterrible at that. Estimate by relative
size: Small, Medium, or Large. Oreven better use the Fibonacci
sequence and estimate the pointvalue for each item: 1, 2, 3, 5, 8, 13,
21, etc.
6. Sprint Planning. This is the first of the Scrummeetings. The team, the
Scrum Master, and the Product Ownersit down to plan the Sprint.
Sprints are always a fixed lengthof time that is less than a month.
Most people now run one- ortwo-week Sprints. The team looks at the
top of the Backlog and forecastshow much of it they can complete in
this Sprint. If the team has beengoing for a few Sprints, they should
take in the number of points theydid in the last Sprint. That number is
known as the team’s Velocity. TheScrum Master and the team should
be trying to increase that numberevery Sprint. This is another chance
for the team and the Product Ownerto make sure that everyone
understands exactly how these itemsare going to fulfill the vision.
Also during this meeting everyoneshould agree on a Sprint Goal,
what everyone wants to accomplishwith this Sprint.
One of the pillars of Scrum is thatonce the team has committed to
what they think they can finish inone Sprint, that’s it. It cannot be
changed, it cannot be added to. Theteam must be able to work
autonomously throughout the Sprintto complete what they forecast
they could.
7. Make Work Visible. The most common way to dothis in Scrum is to
create a Scrum Board with threecolumns: To Do, Doing, Done.
Sticky notes represent the items tobe completed and the team moves
them across the Scrum board as theyare completed, one by one.
Another way to make work visible isto create a Burndown
Chart. On one axis is the number ofpoints the team has taken into the
Sprint, on the other is the numberof days. Every day the Scrum
Master tallies up the number ofpoints completed and graphs them on
the Burndown chart. Ideally therewill be a steep downward slope
leading to zero points left on thelast day of the Sprint.
8. Daily Stand-up or Daily Scrum. This is theheartbeat of Scrum. Each
day, at the same time, for no morethan fifteen minutes, the team and
the Scrum Master meet and answerthree questions:
• What did you do yesterday to helpthe team finish the Sprint?
• What will you do today to help theteam finish the Sprint?
• Is there any obstacle blocking youor the team from achieving
the Sprint Goal?
That’s it. That’s the wholemeeting. If it takes more than fifteen
minutes, you’re doing it wrong.What this does is help the whole team
know exactly where everything is inthe Sprint. Are all the tasks going
to be completed on time? Are thereopportunities to help other team
members overcome obstacles? There’sno assigning of tasks from
above—the team is autonomous; theydo that. There’s no detailed
reporting to management. The ScrumMaster is responsible for making
the obstacles to the team’sprogress, or impediments, go away.
9. Sprint Review or Sprint Demo. This is themeeting where the team
shows what they have accomplishedduring the Sprint. Anyone can
come, not only the Product Owner,the Scrum Master, and the team,
but stakeholders, management,customers, whoever. This is an open
meeting where the team demonstrateswhat they were able to move to
Done during the Sprint.
The team should only demo whatmeets the Definition of Done.
What is totally and completelyfinished and can be delivered without
any more work. It may not be acompleted product, but it should be a
completed feature of one.
10. Sprint Retrospective. After the team has shownwhat they’ve
accomplished during the lastSprint—that thing that is “done” and can
potentially be shipped to customersfor feedback—they sit down and
think about what went right, whatcould have gone better, and what can
be made better in the next Sprint.What is the improvement in the
process that they, as a team, canimplement right away?
To be effective, this meetingrequires a certain amount of
emotional maturity and anatmosphere of trust. The key thing to
remember is that you’re not seekingsomeone to blame; you’re looking
at the process. Why did that happenthat way? Why did we miss that?
What could make us faster? It iscrucial that people as a team take
responsibility for their processand outcomes, and seek solutions as a
team. At the same time, people haveto have the fortitude to bring up
the issues that are reallybothering them in a way that is solution
oriented rather than accusatory.And the rest of the team has to have
the maturity to hear the feedback,take it in, and look for a solution
rather than getting defensive.
By the end of the meeting the teamand the Scrum Master should
agree on one process