An explanation of estimation
(This is an old e-mail I sent a few years ago, lightly edited. See also: my general thoughts on estimation.)
What’s estimation?
The central idea is that we’re generally bad at estimating how long something will take us. We might be too optimistic and not see problems, we might have too many meetings, we might have an off-day, and we might keep getting interrupted by ad-hoc work. However, we tend to be better at estimating relative difficulty of work. So, instead of estimating a piece of work as taking half an hour, we might estimate it as having a difficulty, or hardness, of 1. When we get our next piece of work, we might estimate it as having a hardness of 2, since we think it’ll take roughly twice as long as the first piece of work that we estimated as 1.
The important fact is that these are relative units of measurement – the absolute value of your estimate has no meaning whatsoever.
What’s prioritisation?
Keep a list of all of the work you have lined up. As well as estimating all of these work items, they should also be prioritised – in other words, you should have a queue of pending work.
What’s velocity?
If you split your time into chunks, say of one week, then you can record all of the work you’ve done in a week. If you add up the estimates of all of your work done in that week, that’s your velocity for that week. You can then use your velocities from previous weeks to estimate your velocity in the next week. Once you’ve estimated your velocity, you can work out roughly how many of the items in your queue you can get done next week.
This allows you to work out much you can get done each week, without having to try to work out how much time you spend in meetings, or doing one minute jobs.
What’s wrong with just estimating using days?
If you try to estimate work items in terms of days, you’re probably going to get it wrong. Trying to directly estimate work in days is hard, and the temptation when you get it wrong is to try and work out all the factors that meant you got it wrong (meetings, ad-hoc work, and so on). This turns out to be incredibly hard in my experience, and means you’re trying to solve a problem that doesn’t actually need to be solved.
My view of trying processes such as these is that you can’t control the time element – you can’t directly predict when work will be done, and exactly when you’ll be working on what. Time isn’t one of the levers available to you. Instead, you should control the levers that you do have, such as priorities, and the time taken will drop out of the system. You can then adjust some of those levers based on the time that you’ve worked out, but you can’t control time directly.
What if my units of estimation are different from somebody else’s unit of estimation?
So long as the estimates within a project are consistent with each other, it doesn’t matter if their units of estimation are completely different from another project's (assuming they don't share work queues).
How do I know when a project will be finished, especially when there’s a hard deadline?
Let’s say that there’s a new release of a product that needs to be handled by the marketing department. For this release, there needs to be a video made, some copy written, and some landing pages designed. Each of these work items might go into three different people’s queues. For each item, the person working on that item estimates how long it will take, and adds it to their queue. Using their velocity, they can work out roughly when they’ll complete that item. The project will be finished on the last date that all of those work items are completed.
If it turns out that the finish date is too late and misses the deadline, you could try to prioritise the relevant work items ahead of existing items, such that they’ll be finished before the deadline. This might be possible, but it might also be the case that the existing items can’t be pushed back because of their own deadlines – in which case, that person simply doesn’t have the capacity to deliver what’s being asked of them. We can either find some internal way of dealing with this, such as giving the work to somebody with the time to do it before the deadline, or we can go back to the person who originally requested the work and tell them we can’t deliver by the deadline, and point out the work we already have before that deadline.
Saying yes to a deadline that we estimate we can't meet shouldn't be an option. We might still meet the deadline, but it places an unfair burden on individuals. Overworked people tend to produce lower quality work, and then leave. They also tend to be miserable. As a rule, I prefer not to make people miserable.
What about Kanban?
Kanban is all about trying to improve flow. This means trying to reduce the cycle time of work, where the cycle time is the time between getting a work item and completing it. The idea is that there’s a cost to working on lots of things at once – switching between different tasks takes time, whereas you can get more work done if you work on the same item for a solid period of time. Even without the cost of switching between work items, you’ll also deliver work more quickly if you can work on one item at a time. In a simple model, if you have two work items, and both take a day, you could deliver the first at the end of day one, and the second at the end of day two. On the other hand, if you work on both at the same time, you’ll deliver both at the end of day two.
Kanban attempts to improve flow by limiting the number of things you’re working on at once, known as WIP limits (Work in Progress limits). If you reach your WIP limit, then you can’t start any more work without finishing what’s already in progress. If you can’t make any progress on your current work items, for instance because you’re waiting for reviews from other people, then this forces you to deal with the problems that are blocking progress.