How much time do you invest in estimating your backlog? Do you really get any value from it? When was the last time you thought about the value it provides you? I can see estimation as a source of problems in many ways.
Estimation as a punishment tool
In many companies, estimation is only useful for management to make them believe they have their subordinates under control. “You told me it was going to be done by Friday, why it’s not ready yet?”. The estimation becomes a tool to punish developers when they do not meet it. This is a powerful tool used by management is a double-edged sword. They give you freedom to estimate, but they punish you if you don’t make it. When an estimation is given, it’s like signing a contract with the devil and there is no escape. The first number thrown at the air will become a hard deadline, were there is no other choice than making it. The development team starts over-estimating tasks, to cover themselves. When they know they have spare time, they relax and waste it. Then, they realize it’s too late, and they have to run against any odds to make it. The dev team over-estimates because they do not trust management to adapt when there are problems. Management doesn’t trust developers, because they always over-estimate and waste precious time. This creates an environment where there is no trust, and both management and the dev team get the worst of each.
Useless estimations
Management asks the dev team to estimate tasks before starting with a project. Once everything is estimated in 6 months 25 days and 8 hours and 29 minutes, management comes back and let everybody know the due date for the project is in two months. Suddenly the whole estimation is useless and it was just a waste of time. Not only that, now the dev team knows it’s impossible, and everybody just dedicates all efforts to cut corners. In particular, testing, documentation and all those useless task dev teams put in their estimations, will be the first thing that will not get done. Not only the estimation was just a waste of time, but it also makes clear how important it was for management. Another type of useless estimations is when nobody has a clue about how long it would take to accomplish the task. Then a really high or low number is thrown just to comply with the process. It disrupt metrics and do not provide value.
Agile Estimations
In Scrum or XP, estimations plays a different role than more traditional approaches. They are used to manage how much work is put in an iteration. It’s a way not only to control the Work in Progress for a period, but also plays a role in terms of release planning. Unless you are working in a really stable environment, estimating task to hours or days doesn’t provide any value. Usually agile teams take a more pragmatic approach for estimations. The use of story points, effort points, complexity points, etc. is very common. The points are used mostly to compare sizes of tasks with other tasks they already did. A common practice it to use planning poker which is a fun way to seek agreement within the team. That way the estimation provides a way to find out how much a team is able to deliver in a particular time frame. Of course this is not always exact, but in agile approaches there are mechanisms where the team can discuss with the customer and come to an agreement. In some pseudo-agile places, they follow the whole agile mechanism, but whenever there is a problem, management expects to have everything done by the end of the iteration. They either get everything or the commitment of the team is in jeopardy. Agile estimations work great in agile cultures. Whenever you work with fixed length iterations, you are forced to estimate in some form.
Is no estimation possible?
Kanban introduces so few restrictions which makes task estimation optional. Working with unpredictable tasks, sometimes it’s better just not wasting time on estimating them upfront. Working with the latest technologies or on unknown fields, innovation will likely make things unpredictable. To solve this problem, you can take a more pragmatic approach than the agile way. Kanban doesn’t use estimations to limit WIP, that’s why for Kanban estimations are optional, while in an iteration based process it’s a must. The basic idea is to measure the lead time. An average lead time is used as the initial estimation. This gives a sense of how long it will take to solve it. It’s not a contract, still if there are hard deadlines for tasks, they should be properly noted and prioritized accordingly. Everybody feels comfortable considering the lead time as the initial estimation. The team knows whenever they work on a task, if they realize it will impact a delivery or hard date, they should raise the problem as soon as possible so it gets addressed. This has many implications in the way things are organized, in particular, complete trustfulness is implicit for this to work. So no estimation is possible, in particular when estimation doesn’t provide you any value. Revisit how much value estimations provide you in your environment, and if they are worth the investment. We found that in most cases they didn’t provide enough value to us.
