Differences

This shows you the differences between two versions of the page.

--- what_is_the_purpose_of_estimation [2018/12/20 13:45] – Added q hpsamios
+++ what_is_the_purpose_of_estimation [2020/06/10 12:52] (current) – ↷ Links adapted because of a move operation hans
@@ Line 1: / Line 1: @@
 ====== What is the Purpose of Estimation? ======
-We need to remind ourselves why it is we estimate. Let's face it, estimation is mostly about planning. And there is a huge amount of baggage in most organizations associated with the process of estimation. From the business perspective, the main reason we have to estimate is to provide data to the business (through the Product Owner / Manager) to understand, manage, and forecast the release plan. They are trying to make sure that for a given capacity for the organization (enterprise, program, or team), that we make trade-off decisions about how to best use that capacity, and then understand progress against these decisions. A secondary reason is to help the organization understand their capacity so they do not over-commit and establish a sustainable pace.
+We need to remind ourselves why it is we estimate. Let's face it, estimation is mostly about planning and forecasting. There is a huge amount of baggage in most organizations associated with the process of estimation. There are also legitimate questions the business has:
-I like this quote from Steve McConnell:
+  * When we will get this capability?
+  * How much will it cost to get this capability?
+  * Are we making progress to delivering this capability?
+  * What capabilities are coming up?
-<WRAP box>“The point of estimation is not to predict the future but to understand if we are even in with a chance of managing our way to success.”</WRAP>
+From the business perspective, the main reason for estimates is to provide data to the business (through the Product Owner / Manager) to understand, manage, and forecast plans. They are trying to make sure that, for a given capacity for the organization (enterprise, program, or team), we make trade-off decisions about how to best use that capacity based on the strategy we have and the need for self-investment, and then understand progress against these decisions. A secondary reason is to help the organization understand their capacity so they do not over-commit; so they can establish a sustainable pace.
-The business view of this chance is the forecasted use of capacity. The team / team-of-teams view of this is to work to their capacity.
+Agile requires that we provide the business (through the Product Owner / Product Manager) with good enough data, that we work to improve the estimates when they do not provide the data required. In other words, when we say “make estimation work” what we mean is that the business can easily plan using the estimates and velocity and can make informed business decisions. If the business cannot make it work, it is up to the team / team-of-teams to help fix the problem.
-For many organizations, we need to be able to forecast. As Ron Jeffries says:
+The agile approach to estimation stresses speed, full team involvement, and information that is accurate enough for the purpose intended, not pure precision. This is aimed at reducing the burden of estimation, while still providing the data needed.
-<WRAP box>“Yes, estimation is fraught. It is inaccurate, and politically dangerous. But we do have some knowledge and the project deserves to have it.”</WRAP>
-The process of estimation is not evil in and of itself. But the results are often used for evil. [[http://dilbert.com/strip/2007-12-09|Dilbert summarizes the traditional approach and the way we feel about it.]] Problems include:
-  * Estimates often become commitments. People tend to treat these numbers as factual true data points instead of the probabilistic statements they are, with poor results.
-  * Estimates take a long time. Because we know the estimate is about to become a commitment, we almost do a complete design of the system in order to come up with an estimate.
-  * Estimates are wrong. But even after spending that amount of time on it, the estimates are wrong. And you'll find that the more time you spend on an estimate, the worse it becomes, mainly because you are building your estimate on assumption over assumption over assumption.
-  * Estimates are done by one group. And so do not reflect the total view of what is required to do the work.
-The agile approach to estimation is aimed at improving these outcomes. The agile approach stresses speed, full team involvement, and information that is accurate enough for the purpose intended, not pure precision. What is interesting is that from the perspective of the people doing the work (team / team of teams) the agile approach provides additional reason to do estimation:
-  * Clarity: As teams participate in the estimation process, each skill set brings their viewpoint to the discussion, this building a common understanding of the need and the work involved. Sure the person do the change might think it is a simple change, but the with the testing background might understand that there is a wider impact. Through discussion as a result of estimation, this clarity is built.
-  * Reduced batch size: Estimation helps us forecast work. But what is interesting is that Teams quickly discover (as they analyze the success of their estimation) that the smaller the work, the more predictable their ability to deliver. So the process of estimation actually works to encourage smaller batches of work. Teams will start to establish team norms to say, for example, "if a story takes is expected to take more than 1/2 a week, we need to split it."
-Agile requires that we provide the business (through the Product Owner / Product Manager) with good data, that we work to improve the estimates when they do not provide the data required. In other words, when we say "make estimation work" what we mean is that the business can plan easily using the estimates and velocity we provide to plan a release and make informed business decisions. If the business cannot make it work, it is up to the team / team-of-teams to help fix the problem.
 ====== Want to Know More? ======
@@ Line 34: / Line 21: @@
   * [[can_we_trust_story_points_as_a_measure_of_effort|Can We Trust Story Points as a Measure of Effort?]]
   * [[is_generating_an_estimate_a_waste_of_time|Is Generating an Estimate a Waste of Time?]]
-  * [[blog:our_estimates_are_terrible|Our Estimates are Terrible!]]
+  * [[our_estimates_are_terrible|Our Estimates are Terrible!]]
 {{tag>Team Estimates Forecast FAQ Points EstimationApproach}}