Chris Sims - The Elements of Scrum

The Elements of Scrum

by

Chris Sims

&

Hillary Louise Johnson

For the team:

Betty, Steve & David

*

2011 by Chris Sims and Hillary Louise Johnson

published by:

DYMAXICON

an imprint of

agile learning labs

502 Barbados Lane

Foster City, CA 94404

www.dymaxicon.com

First Edition

ISBN 978-0-9828669-1-7

Youre reading the first published version of The Elements of Scrum. This is the annoying pop-up survey asking you for feedback as we prepare the next version. We want to know what about this book excites, inspires, scandalizes or perplexes you. Love that we included a section on retrospectives? Think the section on test-driven development is too skimpyor that it doesnt belong in a book about scrum? Shocked that we dont capitalize the word scrum? Find a typesetting bug or dangling modifier? Have a burning, unanswered question? Then please head over to the Agile Learning Labs website and let us know what you think.

While youre there, you will also find a wealth of primary sources and other references cited in this book, as well as links to organizations and recommendations for further reading.

www.agilelearninglabs.com/the-elements-of-scrum

Its 9:50 AM on Monday, and Brad is getting ready for his teams sprint planning meeting. Why does he seem so relaxed and happy, whistling while he works?

Brad is the product owner for a high-performing scrum team, and as usual, he will walk into the meeting with a good idea of what he would like the team to work on in the coming week-long sprint. Better yet, he will be greeted by people who are genuinely happy to see him and eager to find out what goodies he has brought. Once upon a time, meeting prep was a sweaty-palmed affair filled with Dilbertian angst, but Brad never thinks about those days anymore.

Brads short list of work items, which includes both new features and bug-fixes, are the ones he deems the most important to complete on the project. He chooses them from a prioritized list called the product backlog, which is part of his domain as product owner.

As Brad selects features, he writes each one on an index card. The team refers to these work items as user stories, or simply storiesand yes, they do think of them as goodies. Coders delight in challenging, interesting work, and since theyve had a hand in designing these user stories, they know the work will be stimulating.

Brad walks into the teams scrum room carrying his small stack of index cards. Frank, the teams scrum master, is already there making sure that the room is ready for the meeting. This is where the team does most of its work, and where they hold nearly all of their meetings. The walls are covered in hand-drawn charts and flip-chart pages with writing on them, including the teams agreed-upon definition of what it means to call a story done.

One entire wall is devoted to the teams task board. This is a low-tech affair, composed of rows and columns marked off with blue painters tape and populated by tasks written on sticky notes.

To the untrained eye the room looks as if a paper bomb just went off, but each and every scribble is a bit of meaningful information to the scrum team members, who like having their tasks, agreements, and progress charts in plain sight at all times. The company execs used to blanch visibly whenever they walked by this perfect storm of a workroom, but theyve learned to trust the teams results; the CFO recently installed a task board for his own team, and has found that the billing department is finally getting invoices to vendors out on time.

Team members Mark and Jeff, the early-risers, are already present. Kira, Justus, Mick, Kai, and Malay filter in to the meeting by 10:00 AM .

Brad starts off: The team has been getting an average of 40 story points worth of work done each sprint. I have picked out eight stories, totaling 40 points worth of work, right off the top of our product backlog. Id like to see if the team will commit to these.

The stories are things that Brad, the business, and the customers want: stories have business value.

The team members discuss each story with Brad, making sure they understand what his acceptance criteria will be: the exact terms by which he will deem each story completed. They talk amongst themselves to understand how much and what type of work will need to be done to implement each of the requested stories.

During the discussion, the team members realize that one of the stories isnt as well-understood as they thought, and they ask Brad to go back to a key customer to get some more information. That story gets deferred, leaving the team with seven stories, for a total of 37 story points. Brad looks through the other items in the product backlog and selects three small stories worth one point each, and the team agrees that they can add these to the plan for this sprint.

There was a time when Brad would have tried to pressure the team into committing to more work, but he has learned that the teams velocitythe number of points it gets done each sprintdoesnt lie. Funnily enough, Brad saw the teams productivity actually go up once the company made a commitment to maintaining a sustainable pace and cut back on the crazy hours (although Malay still likes to burn the midnight oil if he is completely engrossed in a task).

In retrospect, Brad sees that the only thing he ever accomplished by pressuring them to take on stretch goals was to increase the bug count, thanks to the added stress and longer hours. Well, not the only thingthe pressure had also made him a bit of a bogeyman in the eyes of his fellows.

Now the development team trusts Brad, and its members view him as an equal and an ally. He in turn has learned that the team will let him know if they are going miss a commitment, or if they will be able to take on extra work, just as soon as they know it. He feels confident telling the customers that whats in the pipeline isnt a pipe dream.

Its 11:00 AM , and the team moves on to breaking the user stories down into tasks. In order for the team to implement each story, they need to break it down into the actual work tasks that need to be done. The team works together to figure out how each story will be designed, coded and tested. Along the way they record each task that will need to be done on a sticky note.

As noon approaches, the meeting is nearly over and the team has a plan for the coming week-long sprint. They call the plan their sprint backlog: its a list of the stories that the team committed to, along with the tasks that will need to be done in order to complete the stories. They have also added a couple of team-improvement tasks to the sprint backlog: process improvement ideas they have come up with on their own. They write each task on a sticky note and slap them all into the to do column on their task board.

Before the meeting ends, the team uses a page of flip-chart paper to create a chart they will use to monitor their progress as they burn through their tasks over the coming week. They call this their sprint burn down chart.

Tuesday at 10:00 AM , the team gathers in a semi-circle in front of their task board for their daily scrum. The daily scrum is a short meeting that helps the team stay connected and coordinated. It is held standing up to encourage brevity, which is why they sometimes call this meeting the daily stand-up.

Taking turns, each team member shares: which tasks theyve completed in the previous day, which tasks they expect to complete before tomorrows daily scrum, and anything that is getting in their way or slowing them down. Kira mentions that the code in the windowing library isnt behaving as she would expect. Kai offers to help her work it out right after the meeting. Mick says hes having trouble reproducing the bug hes working on, and Justus says that he can help with that. Mick and Justus make plans to team-up right after lunch.