Greetings, salutations and welcome back to the Getting Agile article series. So far we've covered a lot of ground in the previous two installments, from the values and principles of agile to a quick introduction to Scrum.
In Part II, we learned about how Scrum time-boxes development into 30-day increments called "sprints" that begin with a collaborative, one day gathering called a Sprint Planning Meeting. At this meeting the Product Owner, Scrum Master and Development Team get together to lay out the broad brushstrokes for the product that will be delivered, and the tasks required to make them happen. The items that are gathered form the Product Backlog and Sprint Backlog respectively, and are used as the primary inputs for driving the sprint forward to its goal.
In today's installment we're going to zero in on this phase of the sprint and how it all gets started.
Kickstarting The Scrum Process: The Sprint Planning Meeting
When I was a teenager in the 80s, I had one of the coolest home computers around: A Commodore Amiga 500. This baby had it all: multiple CPUs, a RISC based processor, sweet graphics and sound, true multitasking. It was ahead of its time except in one important regard: It had no hard drive. To get it to start, you had to "boot" it with a 3.5" floppy called "Kickstart" that contained the base O/S and drivers. Once this was done, the full power and potential of the Amiga roared to life.
With Scrum, the Sprint Planning Meeting that starts every sprint serves the same purpose as my venerable Amiga's boot floppy: It primes and kickstarts the powerful sprint "engine", beginning with the creation of the Product Backlog.
The Product Backlog
In the previous article, we saw that the Sprint Planning Meeting is comprised of two, four-hour meetings. The first is dedicated to the Product Owner who works with the ScrumMaster and Development Team to determine a prioritized list of the functionality that they want to see in the final system called the Product Backlog. The second meeting is dedicated to the ScrumMaster and Development Team who select items from the Product Backlog list and translate them into tasks for implementing the release.
So what does the Product Backlog look like? How is it assembled? How is it estimated? How are we going to do all of this in a single day?
The Product Backlog begins as a prioritized list of features that the Product Owner wants delivered in their application. Most often, this is tracked on a spreadsheet, however I prefer integrating XP's User Stories at this point for the backlog.
What are User Stories? I'll be exploring them in more detail in an upcoming post, but for now, here's a quick 411: They're brief one or two paragraph descriptions, in plain language, that define how the application should solve a problem or support a business process. They are most often written on 4 x 6 cue cards to keep them to-the-point and to avoid the hangups that using a tool can engender. They are not Use Cases, which tend to be longer and more elaborate.
Back to the Backlog: The Product Owner can either draft these User Stories on their own and bring them to the meeting (if they're really keen), or more likely write them with the team., keeping them cohesive and disaggregating them as required. The Product Owner assigns a priority to each item, e.g. “low“, “medium“, “high“ or “must have“, “nice to have“, “have if possible“.
Finally, the team makes rough estimate assessments of how long each story will take to implement. Usually these estimates are measured in days, but can also be measured on a difficulty scale.
The Product Owner then chooses from the list of “high“ priority backlog enough items to drive a sprint based on the total estimates that the team provided.
What's important to note here is that the estimates the team will be providing are actually more like long-range weather forecasts: They are not exact and are never intended to be.
Estimating the Backlog: Planning Poker
So, how do we estimate Product Backlog? Since this is agile, we favour a decentralized approach that emphasizes people and interactions over processes and tools. How about some planning poker?
Under this approach, each team member is provided a set of cards with the following numbers printed on them in large font: 0, 1/2, 1, 3, 5, 8, 10, 20, 40, 100. These represent an estimate of days for implementing a user story, or the complexity.
The Scrum Master or Product Owner reads the story, and the each member of the team picks a card that they think best approximates their estimate for the story, placing it face-up on the table. Typically, everyone may have different estimates. The objective here is to get everyone to agree on an estimate.
If there is no agreement, two minutes of discussion to hash it out is allowed and the Planning Poker restarts. It continues until everyone can come to an agreement on the estimate, which usually happens by the third round.
Depending on how the number of user stories that have been written, there may be more functionality on the table than can be reasonably delivered in a single sprint. That's ok - for this first Sprint, the Product Owner only needs to select enough estimated Product Backlog to fit the sprint period. Additional Product Backlog can be generated at any time.
Now, there are other approaches to gathering the requirements and estimating them than I've described, such as Wideband Delphi, or XP's Planning Game -- whatever works best for your customer and team. The emphasis here is that the estimates are arrived at collaboratively.
Turning Product Backlog into Sprint Backlog
Once the Product Owner has selected enough estimated “high” priority Product Backlog for a sprint, the second phase of the Sprint Planning Meeting begins. It is at this meeting that we begin to see how an agile team becomes self-organizing and cross-functional.
Working with the Scrum Master, the team sorts through the Product Backlog that was generated during the morning meeting to determine the technical tasks required to implement them. As each task listed, an estimate of 4-16 hours is assessed. If a task requires more than 16 hours, it should be broken down. If the team needs more information to make a decision, it should be able to reach the Product Owner quickly.
As with the estimates that were generated during the first meeting, these are forecasts that are defined by the developers. In actuality, the estimates may prove to be wildly incorrect. Again, this is ok -- as the team becomes more familiar with the problem domain, their forecasts will become more accurate.
As the team is assembling their estimates, the Scrum Master is keeping a tally of the total estimate hours to see if the tasks can fit the sprint period. The team may find as they're estimating the tasks out that they take longer than the product backlog allowed. If this occurs, the backlog either needs to be revisited with the Product Owner and pared down, or the task reviewed to see if there is a less-costly way to accomplish it.
Once this part of the Sprint Planning Meeting is complete, the clock starts ticking: The Sprint begins the very next day!
Summary
In today's post, we've taken an in-depth look at how a Scrum project is "kickstarted" with the Sprint Planning meeting:
- We've learned what constitutes a Product Backlog and how it is developed during the first four-hour part of the Sprint Planning Meeting.
- We've learned about how to define Product Backlog using User Stories.
- We've learned about how to estimate the Product Backlog using "Planning Poker", and that estimates are actually "long-range forecasts".
- We've learned about the Sprint Backlog and how the development team works to transform the user stories they gathered from the Product Backlog into small, estimable tasks.
In my next installment we'll take a closer look at the engine of Scrum, the 30-day sprint, and how it comes together for the team, as well as how it stays on-course for its goal.
Resources