This is a post about prediction.
In the past, estimates were king. If you needed to know how long something would take, you asked for estimates.
However, estimates are personal. It is an individual’s opinion given their experience and knowledge of how long something might take.
As a developer I would hate being asked for estimates.
I knew I would be held to any number I provided. Often given a lack of available information and the pressure for a number an estimate would be pulled out of the air. I then would suffer the indignity of a team leader halving or doubling my estimate depending on who they were talking to. It was clear to me that estimates were never correct (whatever that means) and they generally caused stress and pressure all around.
Now I am frank when I talk to people about estimates. They are a guess, pure and simple! When people ask me for estimates I am vocal that they are asking me to guess. That can make people feel uncomfortable but I’d prefer getting the cards out on the table from the outset rather than everyone pretending that an estimate is something empirical, something tangible or even scientific.
Project Manager (PM): What is your estimate for X.
Developer : Based on what little I know – 2 weeks.
PM: You don’t sound sure – how confident are you?
D : About 60%.
PM: Okay I ‘ll say 4 weeks to be sure.
So the developer guessed. Then said they weren’t that confident. And then the PM doubled the original number. A guess of a guess of a guess!. We use terms like mandays and confidence factor to remove that uncomfortable feeling that we are just making things up. But the result of this guessing process is a number on a project plan. That plan becomes a commitment, often financial, and suddenly you are being asked why you can’t deliver something in the time you estimated.
Instead of feeling bad about it we should all get comfortable guessing!
Looking at chunks of work in terms of their size and complexity instead of the time taken to do them is a good start. You are relatively comparing two things within the same context – A is bigger than B but it is smaller than C. This is how story sizing works. A team uses past experience to size work. Empirical evidence is used to provide a forward projection of how much work can be achieved in a fixed time. The team delivered X units of work in Y weeks so it is likely that if everything stays constant then X units of work will be delivered in the following Y weeks.
The group aspect is often over looked. The work is sized as a group. The work is delivered as a group!
The sizing of the work is independent of who does the work, well it should be if you want your team to be as effective as possible. Different people will have different views of how the work can be completed so it is important to get a group perspective of what might be involved. Do not spend too much time on this. Even when you are sizing as a group it is still a guess. The process can also be incremental. Sizes can be changed when more information is available.
So given the history of the misuse and misunderstanding of estimates I can sympathise when there is a reluctance to undertake any exercise that would provide some level of predictability.
It is naive to think that a team can work in a silo and there will be no one wanting to know when the work is completed. If no one cares enough to want to know when a feature is completed or a bug is fixed then that probably mean that no-one cares about your product. If so why are you doing the work?
So let’s assume that you are doing the work because someone does care, be that a customer you’ll never meet, or a more Enterprisey customer that has made business commitments, or someone who is payrolling your team and wants to see a return on investment.
We are accepting sizing is a guess but that guess can be useful. By comparing your guess against how the team actually performed you can use that to become better at guessing and so better predicting when a feature might be completed or a bug fixed. No one is being held to an estimate. If a piece of work takes much longer than its sizing indicated then this is fine. Use it as an opportunity to reflect, understand what happened and improve the team’s predictability going forwards.
All this is gained from a guess!