Is estimation a waste of time as a number of posts and discussions would have us believe? Or is estimation a core need because otherwise how can we explore or plan? Is there more to this? Let’s investigate.
First a little research into #noestimates yields the following bullet points
Looking at an intro, an excellent article by Ron Jeffries and a point and counter point we can come to a certain understanding that is based on reality.
I have to admit I was struck by Zuill’s comment about being asked to provide estimates at a time in the work where we know least. On the other hand most of the software work I have been involved with requires coordination with other groups. So planning is not optional.
Estimates are often inaccurate, but that’s why we call them estimates. They are not promises and should not be taken as such. They have more use internally to a team than they do externally (IMHO) and the details probably should not be shared externally. The external planning are the committed sprint and PI backlogs which deliver to the agreed objectives. This is what is reported against in terms of management reporting. At least that is what the scrum guide says under commitment: Sprint Goal, and it makes sense. SAFe is of a similar language.
One of the expressions that comes from the #noestimates is that estimation is a waste of time and therefore let’s not do that. Here is where I have a problem. The need to explore features and stories is a fundamental need. How else will the teams come to a mutual understanding of the work and the way forward. When we had disagreements during the estimation progress that is often when real progress was made. Because it identified a lack of understanding about the story being estimated.
#noestimates states that you should break things down so that you are confident you can achieve them in a sprint. This is similar to what sprint planning is looking to achieve with its sprint commitment. So in that respect, not much difference here.
There are some valid questions regarding plans that can be asked. For example:
- What product will we be able to market for Christmas this year?
- How do we plan for the testing and qualification phases of this product? (Assume a high ceremony system such as nuclear reactor safety system)
- When do we need to deliver the training?
- How many teams with what skill sets do we need to hit the annual flu cycle?
When software development is part of a larger product the way it coordinates into the process is important. A number of dependencies are in effect and meeting these becomes a large risk for the work being done.
When we are asked to make a promise with respect to software, we start to play games. For example if we have to meet a date with something, the temptation is to under promise so that we can be sure to deliver. This sometimes even works. There is a clear relationship between the amount of work promised and the chances of meeting a date.
A higher level approach to estimates is the roadmap. Again these are often taken as promises and not the focus of a conversation. Roadmaps are a great source for the goals that are identified for sprints and SAFe PI time boxes.
We have learned that estimation performed by people other than the team is of no value. I do recall in the distant past performing such estimates in the role of the system architect. In hindsight this was quite funny, but at the time I took it very seriously and tried to be accurate and complete. Needless to say I rarely made either of these goals. Why?
- I was the estimator and estimated as if I was doing the work.
- I was working to a written specification that was usually very fictional and also written by another architect.
- The estimation process was based on a flawed system of decomposition by work stream
- As we were not using TDD or any test first, the work was of variable quality and fixing this was often a huge effort and performed under pressure.
- Some people recommended function point analysis, which encouraged big bang thinking, as each release consumed function points to perform.
- I knew only some of the stuff well, the rest I was guessing at using previous results, which were also inaccurate.
- There was no team discussion. When the team saw the estimates they usually disagreed, sometimes loudly.
So where does this leave us?
- Estimation is for the team and the conversations that take place around the estimation process are essential to team understanding and team alignment.
- Estimation is not a promise to deliver, it is part of the larger conversation about the product roadmap.
- Focussing on detailed estimates by external people is never a good sign. This is an example of command and control behaviour which destroys team morale and will yield future estimates with more and more contingency built in.
- When a team disagrees during the estimation process they are in fact learning about the work. Encourage this discussion.
- Work to sprint objectives, and objectives that are part of the roadmap.
- Measure progress through working product.
Leave a Reply