Planning – how we really do it in practice

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. (Read more…)

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. If you still want to know more about how the meeting works, check out Peterstev’s article here).

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.

6 thoughts on “Planning – how we really do it in practice”

  1. What value do you find in treating “high priority items” (#2) and “bugs” (#3) separately, as opposed to covering both types of items under the heading of “high priority items?”

  2. When I refer to Hi Priority items, I am referring to high priority user stories i.e. new functionality that adds value.

    Bugs I always treat seperately. Firtstly I don’t estimate bugs in story points as I do user stories. And generally bugs are not comingled with user stories and tasks. I just think it’s better that way.

    Thanks for the question

  3. Could you explain when you do the sizing of the stories in story points (your prerequisite #2)? This is commonly being done *during* the planning for the iteration, not before it – it is a good practice to reestimate story points for each iteration, even if you have done it during the release planning

  4. You are right, you’re supposed to do this at the beginning of the Sprint planning meeting. However, in my opinion I believe it needs to be done before. If you expect the Product Owner to be prepared and ready for the Sprint planning meeting with a well groomed backlog, then its necessary to provide the Product Owner with estimates earlier on in the process.

    So what I suggest is that you set aside some time each week for example 10% of time each week to do this.

    Hope this helps,

  5. I’ve been using agile methods for about a year or so and I still don’t know how to factor in research! Should these tasks be written up as stories? The kind of things I mean are researching new techs such as in the beginning of projects,say, or in startups when you need to investigate new techs or possible solutions that might not produce a concrete, testable delivery. Even if readers think I’ve missed the point please let me know as I’d like to resolve this for myself and this may help other reltive newbies out.

    Thanks in advance

  6. Most Agile thought leaders will agree that it’s ok to plan a spike. A spike is a body of work that is exploratory .. i.e. research. It’s not always possible to be able to deliver working software at the end of every sprint for all work. Sometimes it’s just not possible. So what you do is you plan a spike which is designed to produce the knowledge on which to base additional planning for future sprints.

    Hope this helps

Leave a Reply

Your email address will not be published. Required fields are marked *