Sprint planning - turning the what into how

What does your sprint planning meeting look like?

Are you the "do it as fast as you can" efficiency hounds or the "sit and listen while the tech lead drones on" type, or are you a "real team" who fight for great designs and customer experiences?

Having watched and attended a few hundred of these meetings over the years I have seen good and bad ones. There are a few key elements that, if missed or undervalued, can lead to constant frustrations and sprint failure.

These elements are:

• Understand your project time


• Your signal to noise ratio


• Starting stories when they are not ready


• Sprint planning is not about writing tasks


• Doing too much planning


• Ignoring your velocity

Understand your Project time

When you are new to Scrum getting a grip on you velocity and thus how much you should plan can be hard. The concept of project time can really help you get to a stable velocity quickly.

Project time is the actual time that you spend focused solely on the project, it's rarely 100% - especially for more senior members of the team.

If each person can guess at the range of hours per day (2-3, 5-6, etc) that they can dedicate to project time, then add the times together and multiply by the number of days in the sprint, you will get a range like this 200 - 250.

You can then use this figure as a quick reckoning tool during sprint planning. So from the example above:

• < 200 = you may need to consider more stories or check current stories for missing tasks


• > 200 and < 250 = within tolerance - make sure you keep an eye on the burn down chart for missed work


• > 250 = you may need to drop some work (don't try to make the estimates fit!) or at least recognise later stories are under threat

It's important to do this not at an individual level but using the team total, this helps to re-enforce that sprint work is a team game.

Once you hit a relatively stable velocity in story points you can drop this practice and you can always go back to it if your retrospectives start pointing to commitment issues again.

What's your signal to noise ratio?

P=a-i or Performance = ability - interference, in Scrum terms Velocity = p - i .

When you sit in your retrospective week after week wondering why you did not make what seemed like a reasonable sprint plan it is time to look at your noise levels. These can kill even the highest performing teams if the noise is not understood or reduced.

Sources of noise include:

• Production support


• Significant multi-tasking (more than one project at once)


• Non project meetings


• Mentoring or management outside of the team


• "have you got five minutes?" requests that take days


• Technical debt that is not being paid back reducing development efficiency


• People being regularly moved from the team

Depending on your work context some of these things you may have to keep doing and some things you should be able to remove or at least reduce. The important principle here is that you understand your noise - get rid of what you can and then model your team capacity (velocity) accordingly. If your organisation wants you to have more capacity (velocity) you have a handy list of things that they can address to give you a capacity boost.

Don't start stories that are not ready

When you start your sprint are stories blocked really quickly? Do you need to spend days doing research before you can start the story? Does your page design get finalised mid sprint, making you change loads of work? When you are sprint planning do you paper over things you don't understand about a story and hope they emerge during the sprint?

If so your team probably does not have a clear understanding of what ready means for you!

A definition of ready works exactly the same as a definition of done, just at the start of a story not the end.

Common items for a definition of ready can include:

• Do we understand any dependencies (other teams, graphics one shot specialists etc)


• Do we have a clear view of business or workflow logic


• Are there major GUI design elements that need to be worked through


• Do any of the acceptance criteria need further detail


• Can the product owner adequately describe the who, what and why for the story


• Have we sized it (not being able to size is a good example of not being ready)

Sprint planning is not just about writing tasks!

Tasks are a useful by product of sprint planning but they are not why you do it.

A pattern I have found productive goes like this:

• Work with the PO to select your next stories


• Look at the stories and order them to reflect this sprint's context (e.g. don't put the stories needing the specialist DBA as the last story if they are on holiday in week 2)


• Take the first story and as a team thrash the hell out of it.
  
  • How do we solve the problem?
  
  
  • How do we build it?
  
  
  • How do we test it?
  
  
  • Does our plan meet the acceptance criteria?
  
  
  • Have we uncovered hidden detail and what do we do, add to story or spin off as a new one?
  
  
  • Are we incurring technical debt, if so what's the payback plan?
  
  
  • Make sure you have plenty of white board space and any details that would significantly effect the story design readily available
  
  


• When you are happy with the story write up the tasks


• Read the tasks back to the team to double check for gaps.


• Repeat this for the rest of the stories


• If you run out of time you should have enough stories to start with.

Doing too much planning

Having just said about doing all that detail you should not do too much of it. Do you find that in the second half of the sprint you have mini sprint planning sessions on the latter stories?

Why?

Well having all of that high powered, high impact conversation is great but it does not stay very long in everyone's head and as the days go by you forget key points, this either leads to bugs and disappointment or a mini re-plan - each is really a waste of your valuable time.

To combat this try splitting your sprints into two halves (or more if team memory is really bad) and do the detail only on a couple of stories at a time. You can also implement a more pull based system and have sprint planning on a story by story basis as each new story is about to be started.

In the end any method will help - just don't try and fit too much detail in your heads at one time.

Ignoring your velocity

Insanity: doing the same thing over and over again and expecting different results.

Albert Einstein

There is an excuse for ignorance, but there is no way to avoid the consequences

W. Edwards Deming

If you did 25 points last sprint what makes you think that you can do 40 points this sprint? Constant optimism will lead to many disappointments.

That said you can ignore your Velocity when you don't know what it is, so when you are starting out it's fine to add some more points to each new sprint until things start to break, then throttle back and get to your steady state.

You may suffer from some or all of these elements over time, just keep your eyes open and make your sprint planning sessions as fun and a powerful as they could be.