Consider getting rid of time estimations
The never-ending battle
Time estimations are one of the major points of conflict between product management and development teams. It takes a lot of time to make good estimations and even then they are usually wrong. I have not encountered many people who could make really good estimations.
There is a reason for that. Estimating software development is really hard. One of the really interesting cases about time estimations is the Denver International Airport Baggage System.
A matter of trust
There are 3 major reasons why time estimations are needed. The first is a commitment made to customers. I will discuss this point later. The second reason is to assist in prioritization, but for this, it is enough to go with t-shirt size estimations which take almost no time. The last reason is trust.
Too many times, management requires time estimations because they do not believe the team will work as hard as it could if they don’t have a deadline.
In my humble opinion, there is no nobler cause than gaining trust as I wrote in Product Management is about People and Trust. I prefer to work as hard as I can on building trust and making sure the team is dedicated, know where is it going, and work hard because they are committed to the cause and not to a deadline.
A matter of speed
I strongly believe that time estimations are good only for a team that is not motivated in the first place. If your team is built of talented and empowered people that are committed to the cause and work hard because they like it, they will work fast.
And as I wrote in Is Scrum Agile Enough, motivated people get frustrated from spending time on planning and prefer using this time on thinking, coming with great new ideas, designing, and developing. Just let them work fast as they can and don’t let them spend the time planning.
A matter of no commitments
You will rightfully claim that you must work with time estimations because you have commitments to customers and commitments to your management. You are right.
If you want to work with no time estimations you need to change the whole process and not just the development process. You need to change how you do your roadmap and make sure you Treat your roadmap as a compass and not as a working plan.
You need to make sure your management doesn’t ask for such commitments, and you need to stop committing timelines to customers except in very rare cases. It means you need to discuss priorities with your customers instead of timelines, and you need to gain their trust. It takes time but it is possible.
If you manage to explain that by not committing you actually serve them and their needs, because it also means that if they need something urgent you can accommodate it and delay the other thing they requested (because you have not committed), they become yours.
Summary
Every team may need a different process. It may well be that in your team you do need precise estimations. I cannot argue with that.
I do suggest that you start questioning this method, and consider whether you can work differently. You don’t need to go to the extreme like me and work with no time estimations at all. But start looking at this matter and reconsider. It may help you in your quest for more trust, more empowered teams, and a better product.
Don't Commit