The following is an excerpt from The Elements of Scrum by Chris Sims and Hillary Louise Johnson. You can buy a copy of the book here.
It’s 9:50 AM on Monday, and Brad is getting ready for his team’s 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 coming 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.
Brad’s 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 stories—and yes, they do think of them as goodies. Coders delight in challenging, interesting work, and since they’ve had a hand in designing these user stories, they know the work will be stimulating.
Brad walks into the team’s scrum room carrying his small stack of index cards. Frank, the team’s 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 team’s agreed-upon definition of what it means to call a story “done.” One entire wall is devoted to the team’s task board. This is a low-tech affair, composed of rows and columns marked off with blue painter’s 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 they’ve learned to trust the team’s 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. I’d 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 isn’t 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 team’s velocity—the number of points it gets done each sprint—doesn’t lie. Funnily enough, Brad had seen the team’s 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 thing—the 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 what’s in the pipeline isn’t a pipe dream.
It’s 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: it’s 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 they’ve completed in the previous day, which tasks that they expect to complete before tomorrow’s daily scrum, and anything that is getting in their way or slowing them down. Kira mentions that the code in the windowing library isn’t behaving as she would expect. Kai offers to help her work it out right after the meeting. Mick says he’s having trouble reproducing the bug he’s working on, and Justus says that he can help with that. Mick and Justus make plans to team-up right after lunch.
The team members update their task board as they go, and everyone finds the ceremony of moving task stickies across the board extremely satisfying. In less than 15 minutes the meeting is over, and the team gets back to work, confident that they are on-track to meet their commitment to deliver the items in their sprint backlog.
At Wednesday’s daily scrum, Brad reminds everyone to take a bit of time before that afternoon’s “story time” meeting to review the short list of new and upcoming stories that he wants to work on in the meeting. When 3:00 PM rolls around, the team gets together to spend an hour refining the stories in their product backlog. Some teams call this “backlog grooming,” but this team thinks that calling it “story time” is more fun.
“I’ve got six stories I’d like to review,” says Brad. “Two are brand new, so we’ll need to do story point estimation for them. The other four are big stories that I’d like us to break down into smaller stories; they are too big for the team to take into a sprint.”
The team examines the four large stories first, finding ways to break each one into several smaller stories, until the four big stories have become 15 small ones, each more detailed than the original.
Now they need to estimate how much work is represented by the 15 small stories and the two new stories that Brad introduced. Scrum master Frank leads the team through an “estimation game” he learned at a conference, which plays out almost like a card game and helps the team reach agreement quickly. By 3:45 PM, the team has assigned story point estimates to each of the stories, and Brad adjourns the meeting.
On his way back to his desk, Brad is thinking about where in the product backlog to put the stories that the team just groomed. He thinks at least two of them are high enough priority that he may put them at the top and try to get them scheduled into next week’s sprint. He’ll slot the rest into the product backlog according to their priority, some near the top, others farther down. Some will likely make it into the next product release, but some will be deferred until later.
At Thursday’s daily scrum, the team identifies a new issue: one of the stories they committed to for the sprint is turning out to be more difficult than they previously thought; the story may not get done, they report.
Brad is upset to hear the news, but appreciates the early warning; he’ll have the chance to manage the expectations of the team’s stakeholders.
Mark and Malay decide to pair on the coding work for the at-risk story, and Mick offers to help automate the tests for it. Towards the end of the day, Kira finishes up another story and asks how she can help Mark, Malay, and Mick.
At Friday’s daily scrum, the team still isn’t sure that the at-risk story will be done in time for the big demo, but they are hopeful. Brad tells the team that he is available at a moment’s notice to answer any questions the team has, or to sign-off on the story if they get it done. Right before lunch, Mark calls Brad over to show him the working software. Is it acceptable? Brad grins and tells the team, “I knew you could do it! Let’s get some lunch. I’m buying.”
Right after lunch, the team assembles for the public finale to their sprint, an event called the “sprint review.” The whole team is there, and they have invited all of the stakeholders to attend. Not every stakeholder comes every time, of course, but most find it valuable enough to attend frequently.
Anne, the VP of sales, has come to the meeting today. The team begins by announcing that they completed all of the stories that they had committed to for this sprint. Then they launch right into demonstrations of the software built for each story. Mick shows off a bug fix that will keep a key client happy. Justus shows the progress he has made in localization for the Japanese market. Finally, the team shows off the story that Anne was most keen to see—the very same one that almost didn’t make it.
After the demo, the team invites the participants to try the new functionality for themselves, ask questions or make suggestions. Brad takes careful notes as the various stakeholders share their opinions of the current state of the product, and which changes they are hoping to see by release time. Brad thanks them all for their input and assures them that he will take it into consideration as he re-prioritizes the product backlog. The meeting wraps up and the stakeholders file out.
The team takes a short break before returning to their scrum room.
Now it’s time for the very last part of the sprint, the team’s retrospective. The whole scrum team is present: Brad, Frank, Kira, Mark, Jeff, Justus, Mick, Kai, and Malay. Nobody outside the scrum team is invited to the retrospective. The team talks openly about how the sprint went, and looks for areas in their process that could be improved.
Mark mentions that the pair programming he and Malay did together went very well; perhaps the team would be willing to pair more often? Kai would like to pair all the time, but others fear pairing might involve too much overhead, especially since the team has a working agreement to code-review all production code.
Jeff suggests that they modify their team agreement such that code could either be paired on, or reviewed. The team agrees. Mark, Kai, Malay, and Kira all agree to pair program at least one hour each day in the coming sprint. Jeff, Justus, and Mick each agree to try pair programming at least once in the next sprint. The team treats the pairing as an experiment, and they plan to review the results at the beginning of next Friday’s retrospective.
Before calling it a day—and a sprint—the team members take a few minutes to recognize each other for all the things that led to the successful sprint. Brad is especially grateful to the team for delivering the at-risk story.
The team members head out to start their weekend feeling good and looking forward to doing it all over again next week.