Tuesday, January 13, 2015

Release Planning vs Sprint Planning

In software development, you can't really get much done unless you plan.  But it is important to understand that there are different types of planning.  And as there are different types of planning, there are also different methods and measures used for each.

Release Planning
For agile shops, the product owner is responsible for the release plan and priority order of the overall backlog.  The backlog is a list of features that are very high level and represent actual value to the customer.  Each item on the backlog represents something that they would like to tell customers about that would make them want to buy the software.  Each item that gets delivered on that backlog represents a conversation with one or more customers and the idea is that those conversations result in sales.  If you talk to the sales people in your organization, they'll tell you that conversations that don't result in sales are the wrong conversations.

So, when we look at release plans, we need to have some idea of how long it will take to get to various points in the priority list.  If a feature is 10th most important, but we know that it will take 2 years before we finish with #9, then it tends to change how we think about our product strategy and we may decide that 10 is really more important than 5 if we want to avoid becoming irrelevant.

To do this, teams will go through some sort of high level estimation.  Most teams these days use what we call 'story points' in estimation.  They are the 'relative' size of features from their peers on the backlog that have a loose ranking to distinguish their size.  Lots of teams use a fibonacci sequence for sizes (1,2,3,5,8,13,21) in an effort to avoid mathematical equivalents to time.  They are not meant to be exact, they are a best guess given the limited amount of information that a team has at the time.

So basically, the release plan will look at the rate in which teams are able to cross things off this list in short iterations and use an average for each short iteration to take an educated guess as to how many items can be crossed of in a given amount of time, or basically in a certain number of iterations.  This 'rate' of completion of the backlog is often referred to as a team's velocity.

Sprint Planning
A lot of people tend to look at a sprint backlog as a subset of a release backlog.  This notion is only partially true.  Most teams don't get to spend all of their time working on features on the backlog...in fact, once you make your initial release, you can expect that your team will likely need to split its focus in at least equal measures between the backlog and supporting existing customers (fixing bugs, investigations, usage reports, etc).  Even before you release, the team often has to spend time doing things like planning, code reviews, setting up equipment, explaining things to salespeople, helping with power point presentations, you name it.  All of which is important, but slows down progress on the backlog.

Since none of these other things are part of the story that the product manager is going to tell customers, then they don't have story points, only the features in the backlog have story points.  For this reason, story points don't make a very good primary input to sprint planning.  They make a decent secondary input as a 'gut check' to ask ourselves questions if we can do more or perhaps we have too much, but most teams that plan their sprint need to account for their time a little more closely in order to have a realistic plan.

I recommend that for sprint planning, teams break down all their work for the sprint into tasks and estimate each task in hours to help them figure out realistically what their capacity is for a sprint.  This doesn't have to be very exact, just rough math will do.  Break down tasks into 4 hour chunks..no less.  Determine how long your sprint actually is, times the number of team members and include vacations, holidays, doctor's appointments or whatever in your tally and try to not exceed 70% of the total number of hours available for all the tasks.

After you've filled up your tasks and added or removed stories or activities to flesh out the plan, total up the story points and ask the question "Does this reflect our average velocity?" and if not, figure out why.  Not matching on average velocity is totally ok so long as you are working on the most important things in your sprint.  If your velocity is lower than average, find out if there are things in your sprint that can be deferred.  If it's really high, make sure your sizing is right and that you've properly identified all the tasks....don't spend too much time on this...just make sure the team all agrees that time is not being wasted.

Relating Sprints to Releases
When you have completed your sprint, you will have burned down most (if not all) of the tasks and if all went well, many of those tasks were part of stories on the backlog.  If we make the assumption that the team made good decisions about what to put into the sprint, then the only thing that is important about the sprint is that progress on your tasks was not detrimentally impeded and that you were able to complete what was committed to.

As a secondary measure, we should look at the number of story points that were completed in the sprint.  Remember though that all of that important work that was done in the sprint may not have story points associated, but was important none the less.  You can't make a linear relationship between the number of points earned during the sprint and how much important work was done.  All you can do with story points is determine how far down the feature backlog you were able to go.

Some other assumptions have to be made here:

  1. You should assume that if in a sprint, you had other important stuff to do that kept you from working on features, that you will likely see more of the same in the next sprint or sprints.  
  2. You should assume that everyone was engaged and working as hard as they should be, and
  3. You should assume that we were working on the most important things
Assuming these things, you have the ability over time to average out your story point velocity and have a good idea of how many iterations it will take you to get to any point on your backlog.

2 comments:

Christopher Myer said...

There was one point though that I think could be discussed further, even as a separate blog post:

"Remember though that all of that important work that was done in the sprint may not have story points associated, but was important none the less."

I think the work that doesn't have story points should be held under a microscope to determine if it is important.  For example, supporting a deploy, is important. But is creating a TODO to refactor some code important?  It depends, I would argue it isn’t if it doesn’t have an upcoming User Story that supports the refactor.  If so then perhaps we should be on boarding that User Story and starting with a technical task that refactors the trouble areas.  I think the same can be said for spiking, sometimes spikes are necessary but I think they should be tasked within the Stories as much as possible, not outside as separate important items.  If we do treat a spike separately it should be in preparation of an upcoming release with the intent to take on the resulting feature work, otherwise we’re just spinning our wheels.  Not to mention the longer the results of a spike sit, the more likely it is to become obsolete.

That’s my two cents.  I like the blog but I think it’s important to make sure that we know what is important if it’s not a User Story, pun intended.

Shawn Crosby said...

Thanks Chris. Great point about being held to task that what is on the sprint is important.

I think outside of the 'keeping the lights on work' like deployments and other tasks that require the team's expertise, I think we have to rely on the backlog and acceptance criteria to keep us on the straight and narrow at all times. Every other item in the sprint should be narrowly scrutinized.