Planning - How We Really Do It In Practice

Introduction
In this article I describe how we do sprint planning at our company with teams of about 10. I take you through a detailed account end-to-end process and cover all the major points.

The importance of planning
Planning the sprint is where it all starts and so it's really important to get this right. It's the foundation on which the next two weeks (in our case) worth of work is based, and without it the sprint falls apart. Set the team up for success by investing the time needed to come up with a well thought out plan. Trust me, it's worth it.

Some assumptions
Now I'd like to preface my detailed account of our sprint planning with two assumptions: 1) You have already prioritized the product backlog and 2) all high priority items are already estimated in story points (at least enough to cover you for the next 2 or 3 Sprints). Prioritizing and sequencing the backlog is best left for another post.

How we really do it
Our sprint planning goes like this:
1) Presentation of backlog items
2) Selecting high priority items for the sprint
3) Selecting bugs and allotting time for refactoring
5) Working out what we can actually accomplish
6) Adjusting the plan
7) Delivering. On time.

During the first part of the meeting we always get the product owner to present the high priority items on the backlog to the team. We include all team members across all functions, i.e. it's got to be cross functional. The product owner needs to give a detailed description of each user story, the intended user persona, and justification on why we're doing it. This inevitably leads to healthy discussion which is very important.

There are 3 buckets of work that we always have to juggle during the sprint planning meeting. New features, refactoring, and bugs. We believe in emergent architecture and as a result we always have some refactoring going on - it's just part of the ongoing evolution of our codebase. Remember only the user stories are estimated in story points and not bugs (See my previous blog post).

Deciding what to do
The first thing we do is schedule the high priority user stories into the sprint. There is always a bit of haggling over how much refactoring and technical debt should be paid down during the sprint. To determine how many user stories we can fit into the sprint we use the average story point velocity (remember, the average velocity should already account for time to fix bugs).

Next we schedule in bug's we deem necessary to fix during the sprint.

Breaking things down
Once this is all done, the team does the task breakdown and estimates how much time it's going to take in hours to complete all the work. We then total the task (user story tasks and refactoring tasks) hours and bug hours to determine the Y-Axis point on the burndown chart.

Adjusting the plan
If that number is greater than the capacity we have available, we work with the product owner to drop user stories from the backlog. There's no sense in having work in the sprint backlog that you know you're not going to get to. If the team has a good sprint you can always schedule in more work on the fly.

So there's a little back and forth that must occur in order to set up a realistic sprint plan that you know the team can deliver on. We always have the product owner on hand even during the task breakdown, in case we need clarification on any of the stories.

If this approach is followed, teams will be best setup to succeed and will be able to maintain a sustained throughput sprint after sprint.

Written by Jack Milunksy - COO at Brightspark, certified ScrumMaster and Co-founder of Agilebuddy (Agile project management software that lets you easily Create, Estimate, Plan and Track your software development projects). For great Agile tips follow Jack at: www.twitter.com/agilebuddy. To get more info on Agilebuddy please visit: www.agilebuddy.com

Comments

[Gil Rooke]

Test: I'm sorry, but the last comment I made failed. I hope this is OK.