Let’s start by setting the scene. If you’re writing software and the work you are doing is so repetitive that you can estimate effort with some degree of accuracy then “Why Don’t You Just Code Yourself Out of a Job and Go and Do Something Less Boring Instead?”
For the rest of us, estimating how long it will take to solve any given problem in code is non-trivial (to say the least).
So if you’re only estimating your work with a single time based measure, whether it be hours, days, t-shirt sizes, points or animals (usually dog breeds) then listen to the #noestimates folk and stop.
If you’re estimating complexity rather than time. If you’ve got advanced techniques that use derivatives of velocity or cycle-time. If you’re doing anything that ultimately boils down to a measure of time. Then in my opinion you’re just chasing the metaphorical bar of soap around the bath tub. Listen to the #noestimates folk and stop.
Good. Now everyone just breath. Don’t worry this is not the end of the story. If you’ve got this far and have, conceptually at least, stopped “estimating with time” I’ll explain why I think it’s a bad idea and if you are going to do estimates then why using time is only a tiny part of the big picture.
How often have you developed something that someone wanted, to only find that once they have it, what they wanted changed? We generally don’t have well defined problems. So trying to estimate how long the solution will take is unlikely to go well for you. The crux of the problem is we don’t have a crux of the problem.
Now the good news. You know all that time you used to spend estimating how long it was going to write the solution? You can now use that to start defining the problem better. I’m not sure I can help much with how to do that, most of what I know about this stuff is hard to write down and I suspect very specific to my environment, experience and customers. My only real advice is go speak to the people who are going to use the software you’re writing, it is their problems you’re trying to find.
So you’ve got a nice juicy problem. Well defined and well understood by the team. Good stuff. So you want to solve this problem. How are you going to do that? My advice is get as many ideas as you can together. Go crazy. Go boring. Go contradictory. Go lateral. Go dumb. The more (different) ideas you have the better. Now it is time to start estimating again.
We’re looking for two things related to each idea. What is the potential upside and what is the potential downside? Good old Risk vs. Benefit. Nothing new here. For each idea we’re asking the team to consider the likelihood that the idea will be successful, and if it is successful, how quickly it will show a return and then how much of a positive impact will it have on our customer’s problem. We’re also asking the team to consider the flipside, the likelihood the idea will fail, how quickly it will fail and if it does go wrong what will be the impact on our customer.
What we are looking for is one or more solutions that are low risk and high return. Simply put limit the downside and maximise the upside. You might string ideas together. So if we do idea 1 first, and it is successful then we reduce the downside risk of idea 2. You might run 2 or 3 ideas in parallel. They all are low risk but chances of success are limited. This helps keep your options open. Maybe you’re unsure about the problem. Pick very cheap ideas that help define it better.
So you can see my concern about time based estimates. The cost of writing the software is such a small part of the overall risk of doing the work, why do we spend 100% of our estimating effort on this small area. Take the advice of the #noestimates people and stop. Instead focus on understanding the problem, maximising the benefits you deliver and reduce the risks involved.
References
gothandy 