Emma Burton – February 14, 2019
If I was asked the difference between computer science and software development (which, as someone who “’about computers, it does occasionally happen), my answer would be something like this:
The hardest question in computer science is “Does P=P?”
The hardest question in software development is “When will your project be done?”
The other difference is that computer scientists never have a senior manager arrive at their desk and say they need “Does P=NP?” answered for a meeting in five minutes.
On the one hand, business decisions need to be made and making decisions requires information. On the other hand, anyone who has ever worked on a software project will tell you that it’s really, really hard to predict how long it’s going to take. The history of our industry is littered with projects running months, years or even decades past their expected delivery date.
Giving a precise, 100% reliable delivery date for your project is probably not viable. But giving no delivery date (the “it’ll be done when it’s done” approach) is usually not viable either. So if you’re the unlucky person who gets asked for delivery dates (manager, PM, lead dev…) you need to do the best that you can.
There are many methods for doing just that. This one is mine.
Step 1: Define your unit of work
For the rest of this process to work, we’re going to need a (roughly) consistent unit of work. While you could use something like ‘story points’ or ‘complexity points’ as your unit of work, I like to keep things simple.
My preferred unit of work is a ‘task’. A task is a single story (or card) on my team’s kanban board, to be picked up and worked to completion by a developer (or sometimes a pair of developers working around one computer).
For the purposes of this process, I assume that all tasks take roughly the same amount of time.
Step 2: Work out your cadence
In project management, the word ‘cadence’ usually refers to the main rhythm a team works by. For example, weekly sprints or releasing every second Tuesday.
My team doesn’t use sprints, and releases can happen at any time, but we still need a cadence. The cadence I’ve chosen is calendar months. This means that I schedule work according to what month it will happen in.
Using a longer cadence tends to give a more consistent velocity, but using a shorter cadence allows us to be more specific with delivery dates. It’s a balance.
Step 3: Measure your team’s velocity
The team’s velocity is the number of work units that are completed on average during the cadence. In my case, it’s the number of tasks completed per month.
Velocity is the dependable Border Collie of metrics. Treat it well, and it help you with a diverse range of problems. It may actually be the only metric you ever need.
I track velocity over time as a pretty graph, a bit like this one:
The graph is helpful because it shows visually how much the team’s velocity varies over time. A flatter graph generally means better predictability, which is helpful when providing delivery dates.
Side note 1: If the graph has an overall upwards trend (implying increasing productivity), this can lead to a warm, fuzzy feeling. It can be tempting to share the warm fuzzies by showing the graph to management. Don’t do that. Metrics that become too visible can easily become targets, and metrics that become targets cease to be useful metrics (because people end up gaming them). Don’t destroy your most useful metric.
Side note 2: It’s worth questioning months that don’t seem to fit the trend, even if the answer is often something obvious like “April is low because half the team went caving together for two weeks”. The insights can help predict future ‘special snowflake’ months.
Step 4: Estimate the size of the project
A lot has been written about how bad people are at estimating how long something will take. So instead of estimating the size of the project in time, I prefer to estimate it as a number of units of work. In my case, individual tasks.
I find it helpful to write down a list of the features, then decide which features could probably be implemented using a single task, and which will take multiple tasks. Then add more tasks depending on how many unknowns there are. Having things in the list which just say “Logging??? (2 tasks)” is fine. This is a project size estimate, not a specification.
Step 5: Give a delivery date
Finally, we can put it all together. If we know the size of the project (in units of work) and we know our velocity (in units of work per period of time), then we know how much real time the project should take.
So the time to complete your project is just this:
Time to complete project = Size of project / Velocity
There’s a very important (and perhaps obvious) caveat here: this assumes your project can be parallelised enough to occupy your entire team at once. In reality, it’s important to think about how much of the team could probably be occupied at once for the project’s duration, and divide your velocity accordingly. Half the team will have half the team’s total velocity, etc.
Once you know how long the project will take in calendar days, just add that to the date you plan to start.
Congratulations, you have provided a delivery date for your project.
Some warnings and pitfalls
Of course, if it was that simple, no one would hire Project Managers. So here are a few things I’ve discovered that can scupper best laid plans:
Target delivery dates vs committed delivery dates
Not all delivery dates are created equally. There’s a big difference between “The product team want to know which quarter they should expect this” and “The legal team need a delivery date for the client contract”.
When giving a hard delivery date, always buffer. How much you buffer by is a function of your team’s predictability (see that velocity graph from earlier) and the consequences of being late. In the past, I have buffered by 50% when giving delivery dates to clients (on projects of up to three calendar months). But for large projects with dire consequences for lateness, buffering by 100% is not at all ridiculous.
This is one of the many situations where open and honest communication helps a lot. Talk to your stakeholders (both internal and external) about what a delivery date really means in this context.
Consistent task size
You may have noticed that in Step 1, I assumed that all tasks (or stories) on my team’s kanban will take approximately the same amount of time. On the surface, this might seem like a dangerous assumption to make.
My policy is based on the following assertions:
- If we are measuring our velocity over a large number of tasks, it’ll all average out in the end.
- If all the tasks are kept as small as possible, they’ll be closer in size anyway and average out faster.
- Keeping tasks small is more agile, so worth doing anyway
To help keep them small, all tasks are reviewed by the team before being accepted into the queue. During that review, we ask the question “Would I be comfortable getting this done in a week?” and if the answer is “No” we split it into smaller tasks.
Of course, no matter how much you focus on trying to keep individual tasks small, there will always be the occasional one which ends up taking way longer (even orders of magnitude longer) than the average. Managing this problem is a whole topic in itself which goes way beyond giving a delivery date, but it helps to think about which of your requirements has a risk of ending up more complicated than intended and add more buffer there. If I suspect a particular task may be a total pain, I assume it will actually take two tasks to complete.
So that’s a whistle-stop tour of how I give delivery dates. It’s definitely not a cure-all. Project management is hard; and every industry, organisation and team is different.
My philosophy can probably be best summed up as…
- Keep the process as simple as possible. Complexity will trip you up.
- Take measurements. Gut instincts are often wrong.
- Keep improving. It’s a journey.
But if I had to choose just one piece of advice on how to give a delivery date, it would be this:
You are being asked this question because you are in a better position to answer it than the person doing the asking. A delivery date is only worth anything if people believe in it, and that belief starts with you.
So take your measurements, make your estimates, execute your process and then give your delivery date.
Now smile. That was the hardest part.