Effective Planning

Don't.

Sprinting or Pulling?

There are two really popular Agile approaches, Sprints and Kanban. Sprints are about creating time-boxed iterations where you get to pretend for just a little while that the world is calm, things don't change, and nothing unexpected will happen. Kanban on the other hand is like a beleaguered parent taking a reluctant child to school, pulling them along the hallway as they kick and scream and generally try to escape.

Maybe you've done one in the past, maybe you've done both, maybe they both worked, maybe neither did, but either way for now let's assume that you've got some work to do and you've got a team to do it, and you've got a stakeholder who wants to know when it's going to be done. Sadly this stakeholder is also paying us so we can't tell them to shove it. In order to forecast we're going to need a few things:

1. An idea of the rough size of all the work
2. An idea of how quickly we can do each piece of work

The second thing is your velocity and the primary difference between Sprints or Kanban is that in Sprints you have a nice fixed denominator for this velocity - the Sprint.

What I've found is the best way to think about when you should do Sprints or Kanban is that if there are people truly "depending" on the work you're doing then you should be doing Sprints. On the other hand if the primary reason you're estimating is to keep your stakeholder happy then you should probably be doing Kanban.

Estimating the Backlog

I don't care if people don't like story points, I like them and they work. For estimating our team / product backlog we're going to use story points.

Story points are a relative estimate of a task - what about the task? Either it's "effort", "difficulty", or "complexity" are the general guidance for what is being estimated, but by and large at the point of estimating work in the backlog those 3 things should be so similar and linearly related that it doesn't matter. When we say they're relative it means that story points can be used to determine if something is about the same size, about half or smaller, or about twice or bigger the size of something else.

In order to establish the "something else" we pick a series of reference features - canonical stories - these are useful as guideposts around which estimating can be done. When estimating new work we compare it against these canonical stories and ask "bigger or smaller?" this will eventually get you to the boundaries, bigger than This but smaller than That. Once you have the boundaries of the size you should assume the worst and pick the upper boundary for the size of the new work.

When estimating there's often uncertainty about the work. People may complain and say that they have to do research, or go and test something out. But that research is work, it takes real time and resources, and especially if the features your estimating aren't something you'd immediately jump into that research is going to be wrong by the time you get to actually building the feature. Rather treat uncertainty as scope and estimate higher. If the estimate is "too large" then buy information by doing the research work.

The Precision and Accuracy of the Fibonacci Sequence

Many teams use a Fibonacci or modified Fibonacci sequence for story points. I like this because it helps to clearly establish the relationship between precision and accuracy. Say we have a feature we can accurately estimate that it'll take between 1 second and 1 year to complete, we could also precisely, but incorrectly, estimate that it will take 5 hours 37 minutes and 42 seconds. Neither a precise inaccurate or an accurate imprecise estimate is particularly useful. Instead what we strive for is finding the sweet spot between precision and accuracy that is right in the context in which we're estimating.

Generally speaking you want features to be small and actionable by the time you get to actually building them, the Fibonacci sequence gives us some nice small and precise numbers down at the lower end of the scale: 1, 2, 3, 5. Generally everything that is going to be done in the near term should be estimated in this range. Work that is further out will likely be bigger because it's not as well understood - less actionable. Again the Fibonacci sequence gives us large and less precise numbers to work with: 5, 8, 13, 21. Here the gaps between the numbers are larger giving us more room for those unknown unknowns.

We shouldn't be afraid to use even larger numbers if we need to - 34, 55, 89... these numbers represent features that may take a team a whole quarter to complete, before they get started we'll have to carve them up into smaller pieces, answering questions along the way and putting smaller estimates on the individual parts.

What do we do with the estimates?

Story point estimates are not for planning the current work - we'll get there. What they are for is forecasting future work. By measuring the number of story points that a team completes over a fixed period of time (like a Sprint) we can calculate a velocity. With our velocity in hand we simply divide the total amount of work we want to get done by the velocity to get the amount of time it will take. Alternatively you multiply your velocity by a fixed amount of time to get the amount of work you can expect to get done. These are respectively fixed scope and fixed time forecasts.

If a team is achieving a very stable velocity than simple division or multiplication will suffice, teams that have more variable velocity require more variable forecasting tools. One personal favorite is a Monte Carlo simulation - you simulate many times using random completion amounts based on a distribution that is driven by the historical data. You can extract information like the min, max, and 90th percentile from the simulations this produces a clear range that you can communicate to stakeholders.

What not to story point

Since story point estimates are for forecasting it's important to follow 2 rules:

1. Do no re-estimate work after it's been completed. This is a common way for teams to make sure their velocity is giving them "credit" for the actual complexity of the work they're doing, but it also means that their velocity is effectively measured in a different set of units than the work in the backlog.
2. Do not estimate unplanned / unprioritized work. Specifically things like bugs that are brought to the top of the backlog should act as a drag on the team's velocity, since the expectation is that going forward more bugs will be found and moved a head of other work. I would also generally put technical work in the bucket of "unprioritized" since it's often work that is done on an as needed or opportunistic basis and doesn't have a clear priority.

Planning actual work

Whether you're working in Sprints or Kanban there's a point at which the "actual" work is going to start and it's not going to be time to think about story points anymore. When you get to this point it can still be valuable to estimate and plan work. One reason in particular for this is to help with the communication to your stakeholders. If you're going to fall behind on work anyways it doesn't help that you had a plan, but what does help is being able to communicate clearly and as early as possible with your stakeholders that something is not going to plan.

For the purposes of this discussion let's assume you're planning a sprint. The first thing you need to understand is your capacity for work, there are many ways to determine this but what I'd advocate for is a simple accounting of the contiguous blocks of time that each team member has available. This takes into account things like meetings, travel, and other commitments - things that are not modeled in your story point velocity. For the purposes of planning a sprint I would usually ask for "half-day" granularity in capacity estimates. That means that each team member can count the number of "half-days" they have available (that being 2 - 3 hour contiguous blocks of working time). After that you apply a per-person scaling factor. This factor is entirely at the discretion of the individual, in general more senior team members tend to have a lower scaling factor representing the uplanned work like mentoring, or incident management that they are expected to do. All the team's scaled half-days of availability are pooled together and the result is further scaled down, this time by a team factor. This factor is something the team should own and discuss during retrospectives or before planning. If teams are consistently under delivering then they can decreased this scaling factor, if they're consistently getting all their work done and pulling in new work, than they can increase the scaling factor.

The end result is a number of half-days of "team capacity". In the case of teams where there is a non-homogenous mix of skills and work it can be useful to break down the capacity into seperate buckets, however you should do as-few of the these as possible.

Now with the capacity in hand you can start to break down individual features into concrete tasks that are given half-day sized time estimates. As you do this you deduct capacity from the team's available capacity. Eventually a feature would put you in the red and you're effectively done. When looking at the features that do fit in the sprint you may want to consider making some swaps, use time estimates to do so.

With the sprint planned the team should accept the sprint and commit to getting it completed.

Why use time instead of story points?

Story points are a good tool for estimating features because they don't ask someone to put a time estimate on them, instead focusing on the complexity or general effort of the work. However at the point of planning a sprint we should have a solid understanding of the work, and the actual effort involved. Additionally it's really hard for anyone to measure their actual capacity in story points without creating individualized velocities. Take for instance a team that is going to a conference for the last 2 days of the sprint, they clearly lack the capacity to take on a normal workload but to account for this in story points you would need to estimate the size of the conference, which would in practice be generating a blended per-day velocity for the team. This is a lot of work and it's not particularly accurate. Instead we can use time, people can assess their availability in time easily by looking at their calendar. Estimating time trades accuracy for precision, but by using 1/2 day increments we get some of that accuracy back.

Oh Crap!

So you've planned a sprint, obviously nothing will upset the plan...

But if something does throw the plan off:

1. Don't panic, this is expected
2. Estimate the new work
3. Replan what is left of the sprint

Replanning is an easy exercise - you start by estimating the time needed for new items that want to come into the sprint. Then you look at the time estimates for the remaining items. Everyone looks at their calendars and the team asks "are we ahead of the plan, and can add this work?" If the answer is yes then the team commits to the added scope and moves on. If the answer is no then the team works with stakeholders to find something of equivalent size in the current sprint to swap out.

If there isn't work large enough to swap out for the new work then the new work is too large to fit in the sprint, the team should break it down and do it over 2 sprints. On the other hand if nothing is low enough priority to swap out then the team should move the new work into the backlog and look menacingly at whoever made a big deal about this work when it wasn't actually something that needed immediate attention.