Anyone who knows me knows I’m not a fan of estimation. Asking a team how big something is when they know the least about the item seems like a bad idea, but I do understand the need to know how long something will take.
I was chatting to one of the leaders I’m currently working with when this came up (again) and she asked me ‘if you took your car to a garage wouldn’t you want to know when it will be ready?’. To which my answer was, ‘I did exactly that this morning and it didn’t even occur to me.’.
There is a reason why I didn’t ask the ‘how long’ question, and its 2 fold. Firstly I understood that the mechanic would have to look at the car and diagnose what was wrong with it first. In this instance the heater wasn’t working and my concern was that there was something wrong with the coolant system that could potentially lead to the engine overheating and fusing. It could have been something very simple like a blockage in a pipe, or it could be a thermostat, or well, any number of things.
Secondly, I din’t ask how long because I trust this particular mechanic enough to know I’ll get a regular update. This is key. I knew from track record that once he had diagnosed the problem he would call me and explain whats wrong and then would be able to tell me what options I have and give a rough idea of effort involved for each option. Then I could decide if it’s something I wanted to fix now or something that could wait until later.
As it turned out he checked the computer system and it told him there was some mechanical problem that was causing the hot air to not circulate, but the coolant system itself was fine and there was no danger to the engine. He managed to manually crank it a couple of times as a quick fix, but wasn’t sure if it would break again. To solve the problem more permanently he would have to dismantle the dashboard to get access to the parts to clean or replace them. I could tell that would be quite a bit of effort. In the end I was happy with what he’d done as my main worry was the risk of a damaged engine, and I picked the car up the same day I dropped it off.
Relating this back to an IT delivery team. Big up front design is a no no, and thats the only way you can get an idea of time and cost (even then it’s still a guess). Instead of that we should be listing what features we want in a backlog that is not estimated. We should know what is more important than the other in our backlog and be able to prioritise it based on value to the customer or logical sequencing. Then when it comes to breaking the items down in refinement the team can help give us options on those features, do you want the quick easy fix? or something a bit more elaborate? or something in between? We can understand the options and then figure out which way we want to go. If pressure is on, maybe we want a simple solution now, with a view to expand on it later. If it’s a key feature, maybe we want to put more effort into it and not worry about what is next right now.
Once those decisions have been made the team can pull it into their planning session and start to really break down the work into tasks that make sense. These tasks can probably be estimated in some way to help the team know how much to pull in for that given iteration.
So in summary, I don’t believe a backlog should have all its items estimated, I think this is waste, and too much guess work to be valuable. It’s good enough to know if this is a big piece of work, or something quick to do. More important is to know what the options are and not be set in stone on how something should be delivered too early on. That can come later.
There is value in estimation when breaking down tasks so the team has information to know how much it can bring in to an iteration, but those estimations are for the team and team only, nobody outside the team should ever care.
From a business point of view, as long as they are receiving value every iteration, and are getting constant feedback and seeing progress, they will learn to trust the team and not worry about ‘when will feature A be done’. In terms of the bigger roadmap and releases there are ways to monitor the flow of work and understand the throughput of the team to get a rough idea of when something can be released to the public. We can talk about that another time…