what_is_the_purpose_of_estimation
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revision | Next revisionBoth sides next revision | ||
what_is_the_purpose_of_estimation [2019/01/16 08:55] – Added emphasis hpsamios | what_is_the_purpose_of_estimation [2019/01/21 08:12] – Significant refactor to isolate chapters hpsamios | ||
---|---|---|---|
Line 8: | Line 8: | ||
* What is capabilities are coming up? | * What is capabilities are coming up? | ||
- | From the business perspective, | + | From the business perspective, |
- | For many organizations, | + | 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. |
- | + | ||
- | <WRAP box> | + | |
- | + | ||
- | Estimates are not evil in and of themselves. But the results are often used for evil. [[http:// | + | |
- | + | ||
- | * 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. | + | |
- | + | ||
- | <WRAP Box>The agile approach stresses speed, full team involvement, | + | |
- | + | ||
- | 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: Teams understand the type of work they do and what the market is asking for. They can ask clarifying questions to make acceptance criteria detailed enough for them implement the work. Through discussion as a result of estimation there is increased clarity for the whole Team. | + | |
- | * Knowledge transfer. | + | |
- | * 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." | + | |
- | + | ||
- | I like this quote from Steve McConnell: | + | |
- | + | ||
- | <WRAP box> | + | |
- | + | ||
- | 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" | + | |
====== Want to Know More? ====== | ====== Want to Know More? ====== |
/home/hpsamios/hanssamios.com/dokuwiki/data/pages/what_is_the_purpose_of_estimation.txt · Last modified: 2020/06/10 12:52 by hans