The Art of Doing Twice the Work in Half the Time (Essence)

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