 |
This section of the portal is for supporting the Disciplined Agile Value Stream Consultant Workshop (DAVSC), currently under development. Discussions on the pages here will take place on the Disciplined Agile LinkedIn group. |
There are three disparate views on estimation. One is that estimation is harmful because management misuses the estimates, another is that estimation is a form for waste because it doesn’t provide value directly, and a third is that estimation is critical in order to do planning. Let’s discuss each of these views and see what we really need to do regarding estimation. The origins of most of the conversations of these three camps are #noestimates twitter community (believing estimates are misused by management), Kanban (believing it’s waste), and Scrum (believing in estimation).
Different Attitudes Towards Estimation
The #noestimates Twitter community
This movement was started by Woody Zuill, a consistently out of the box thinker, to engage in the conversation of where estimation was valuable. It was not his intention not to do them ever, but rather learn where they are valuable and where they are not. It has morphed into its current state where people talk about the lack of accuracy of estimates in general and their lack of utility because of it.
We have found that poor estimation is usually due to being unable to anticipate the added work created by interruptions and technical debt and not so much due to developers not understanding what it takes to get the work done. This information can be useful to identify challenges that must be solved. In any event, there is no need for each estimate to be accurate. The intention is for estimation to be generally accurate across the sum of the estimates. This is not impossible to achieve and provides enough basis for computing a consistent velocity on a team-by-team basis.
The “estimation is waste” community
Estimates are sometimes called waste because they provide no direct value. However, they are often useful for coordinating teams. They can also be useful to make sure people align on what the item being estimated is. Finally, it is often a good practice to break larger stories down into smaller stories that can be completed in a fraction of an iteration. It is not wasteful if it enables delivery of value quicker. The key is not to dogmatically call it waste without a discussion, but to determine if true value add is being provided.
The Scrum community which requires it
Scrum, and approaches based on it, such as SAFe, require estimation. If you are doing Scrum, you should be estimating. An alternative would be to do Kanban which doesn’t require it but still can have many of the Scrum ceremonies. While many in the Scrum community complain about the time it takes to do estimation, this is mostly due to using Planning Poker.
Planning poker is definitely useful in some situations and is easy to learn. However, for the very reason it is effective in some situations, it is very inefficient in most. Planning poker requires more conversations than the other methods introduced here and this slows things down. The relative estimation method used is also less efficient than what is used in the alternative methods. However, if you need to get a team to talk, Planning Poker may be your best choice.
Different Types of Estimation
Using story points
There are many ways to size stories such as T-shirt sizes, hours, ideal engineering days, and story points. Industry thought leaders who agree on the need for estimation generally recommend using story points. See Agile Estimation: 9 Reasons Why You Should Use story Points for the reason why. When using story points, it is also suggested you use the modified Fibonacci sequence to size your stories. This limits your choice sizes to: ?, 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, 200, 300, infinity.
Alternatives to Planning Poker
There are two popular alternatives to Planning Poker that are 4-10 times more efficient (meaning that they take 10-25% of the time that Planning Poker takes) while still achieving similar estimation quality. These methods are Steve Bockman’s Team Estimation and James Grenning’s Planning Poker Party. Both are much more efficient because they use true relative estimation (i.e., you first compare the stories/features with each other, making similarly sized groups) and then you assign them values.
When estimation is not needed
If you are in a maintenance organization, planning may be unnecessary. But if you are needing to plan out multiple releases and/or need to take advantage of team-members whose skill set/abilities/experience is in high demand because few have it, estimation is often essential. The mantra of “no estimation” seems to me to be a reaction of inefficient methods in the Scrum camp and an over-enthusiasm for the Lean mantra of eliminating waste from the Kanban camp. Actually, I don’t like “eliminate waste” as a Lean Software Development mantra. It is too easily confused and taken up by folks who aren’t really clear what waste is. Not all planning is waste. Not all estimation is waste. It depends how you do it.
Sometimes people believe estimation is required by stakeholders. Very often stakeholders are demanding estimates because they believe it is one way to raise productivity. It often isn’t. In many situations it doesn’t need to be done for them. In some situations it is actually useful for the team. So in making the decision, the entire workflow from initial request to deployment should be considered.
Summary
If teams want to not do estimates because of what management does with them, then we have a problem between management and teams. Just avoiding the estimates doesn’t solve the problem. Always go to what you are trying to achieve and why when looking at practices you are undertaking. If estimation is taking more time than it’s worth, see if there are more efficient methods than what you are using. Don’t throw out the baby with the bath water.
This chapter was an excerpt from FLEX for the Disciplined Agilist: FLow for Enterprise Transformation (online book). It has been edited to fit into the Disciplined Agile Value Stream Consultant workshop. The Table of Contents for the book is here.