Scrum thoughts: sprint planning
Series [ Scrum Thoughts ] Tags [ availability, confidence, Scrum, Scrum master, sprint planning, tasks, Trac ]
If you’ll recall from my earlier post about pre-planning, we enter into our sprint planning meetings with a stack of user stories written on large index cards.
The first thing we ask everyone to compute is the number of hours they have available for the sprint, starting with number of working days, subtracting out holidays/vacation, and then using a general availability of hours per day of productivity. We’ve tended to use 6 hours per day per developer, although not everyone uses that rate, particularly tech leads and team members doing double-duty as scrum masters. For these special cases we ask each member to take a guess at the number of “burnable” hours per day they will have available. Each person writes the total number of hours down on a piece of paper in front of them.
We distribute a bunch of post-it note pads and pens around to the entire team, who sit around a large conference table. We have our product owner take each user story in turn and elaborate on it. The team then poses questions to refine the requirements, and brainstorms a plan of attack. Then the fun part starts.
People start signing up for work. We’ll identify all the tasks, and as we go, people will write themselves tickets on a post-it. The tickets contain a task description, a name (who has signed up for it), and an estimate in hours. When we’re done, we collect up all the post-its and keep them with the user story index card. Then we move onto the next user story.
This makes for a pretty big flurry of activity – everyone is participating, writing tickets, brainstorming, load-balancing tasks. It is anything but boring.
Each person is then responsible for keeping track of their committed hours (I just keep a running tally, subtracting each ticket’s hours off my initial availability total). We then use this to assign confidence levels to each user story. If I am within the first 50% of my total available time, I’ll mark my tickets with an H (for high confidence). When I’m in the 50-80% range, I mark them with M (medium confidence), and tickets written against the last 20% of my availability are marked L for low confidence.
The overall confidence for a user story is the lowest confidence of any of the constituent tickets. So just one person working on a story with a M ticket will make the whole story medium confidence, even if everyone else has H tickets against that story. The thought here is that you need all the tickets to actually complete the user story. This works out great for communicating back to the product team (and senior management), as it neatly captures the “cone of uncertainty” around the stuff that’s furthest in the future. If all goes exactly according to plan, you get everything, but if something takes slightly longer, and a low priority user story gets bumped off, people might be disappointed, but no one is surprised.
Generally, this sprint planning process is one of the things I think we have nailed. There are a number of good features about it:
It’s fun! We used to sit around and have someone recording the tickets in a spreadsheet on a laptop while everyone else watched, and man was this a low-energy, spirit-sapping exercise. It’s much better to get everyone involved, and people get to write the ticket description exactly how they need it worded.
It’s pretty accurate. We used to not assign tasks to specific people, but rather just generate all the tasks and manage them as a big to-do list where people would just pick off the next task they could do. The problem was that we would argue about the estimates, failing to take into account differing skill levels of different team members. Now, the person doing the work owns the estimate.
It’s pretty fast. Because a lot of the discussion and ticket writing happens in parallel, you can chew through user stories pretty fast.
The main downside to this approach is that the poor scrum master has to take all the index cards and post-its and enter them into our ticketing system (we use Trac. Usually the scrum master can get away with entering all the tickets into a spreadsheet, and then we have some scripts that import them into Trac. Ideally, I think it would be fun to just use the index cards and post-its and keep a team wall going, but we’re pretty cramped for space, and wall space is in pretty short supply.