Differences

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

--- is_generating_an_estimate_a_waste_of_time [2020/06/10 12:44] – ↷ Links adapted because of a move operation hans
+++ is_generating_an_estimate_a_waste_of_time [2022/04/08 09:41] (current) – [Is Generating an Estimate a Waste of Time?] hans
@@ Line 1: / Line 1: @@
 ====== Is Generating an Estimate a Waste of Time? ======
-I often get questions like "Could you please let me know your opinion on "No Estimates" as we have been hearing this lately very frequently and going through some literature have put me in more confusion."
+I often get questions like "Could you please let me know your opinion on 'No Estimates' as we have been hearing about this idea recently and, going through some the literature we are now confused."
 So here are some thoughts.
@@ Line 11: / Line 11: @@
 OK, so getting past the base question, I like the thinking behind #noestimates, and I think there is a lot of confusion. To me the #noestimates tag is a (purposely) extreme label design to encourage conversation. The label is really about looking at the estimation process and deciding whether it provides value (to the business). Even the #noestimate people don't seem to say "there are no estimates" but rather they say "this is how we will get this information that we need".
-When I first heard about the concept, there was a discussion about "how to forecast delivery of a feature". Note the change in terminology here - the end result is not an estimate, but a forecast plan and the idea of presenting it this way is to say "perhaps we don't need to do normal estimation to get this information." In this case the discussion turned into one about using cycle time (how long does something stay in progress once we start working on it on average) to indicate when a feature gets delivered. And this lead to the interesting observation, that I was able to repeat, that you can often replace point / velocity based reporting with simply story counts (what I call card counts) to show the same progress (see [[do_we_need_points_to_generate_a_release_burn-up_chart|Do We Need Points To Generate a Release Burn-up Chart?]]).
+When I first heard about the concept, there was a discussion about "how to forecast delivery of a feature". Note the change in terminology here - the end result is not an estimate, but a forecast plan and the idea of presenting it this way is to say "perhaps we don't need to do normal estimation to get this information." In this case the discussion turned into one about using cycle time (how long does something stay in progress once we start working on it on average) to indicate when a feature gets delivered. And this lead to the interesting observation, that I was able to repeat, that you can often replace point / velocity based reporting with simple story counts (what I call card counts) to show the same progress (see [[do_we_need_points_to_generate_a_release_burn-up_chart|Do We Need Points To Generate a Release Burn-up Chart?]]).
 What did I conclude from this? I started to think about why I was getting this counter-intuitive result and, after a number of discussions figured out that the process we go through when we estimate (i.e. big things are split into smaller things etc) meant that we end up working on small stories and this means is that card counts and story point velocity end up measuring the same thing.
-Now why do I bring this up? Mature teams have a characteristic that they burn completed stories (running tested features) all the time during a sprint. In other words for a 2 week Sprint, they complete the first story after a couple of days, the next a couple of days later and so on. They do not have the mini-waterfall effect that all stories are completed on the last day of the Sprint. To me this is why a mature team might be a better candidate for the successful use of a #noestimate approach, but that does not mean that that the approach cannot be used by non-mature teams. We could use a #noestimate approach to drive to the delivery of small units of value (for example, team says "maximum size of a story is something that can be completed in 2 days" - a form of 'estimation' but a different approach) and that would be a good thing irrespective of the estimating approach.
+Now why do I bring this up? Mature teams have a characteristic that they burn completed stories (running tested features) all the time during an Iteration (Sprint). In other words for a 2 week Iteration (Sprint), they complete the first story after a couple of days, the next a couple of days later and so on. They do not have the mini-waterfall effect that all stories are completed on the last day of the Sprint. To me this is why a mature team might be a better candidate for the successful use of a #noestimate approach, but that does not mean that that the approach cannot be used by non-mature teams. We could use a #noestimate approach to drive to the delivery of small units of value (for example, team says "maximum size of a story is something that can be completed in 2 days" - a form of 'estimation' but a different approach) and that would be a good thing irrespective of the estimating approach.
 Like a lot of agile ideas, I don't think this is a black and white discussion. If we evolve forward in our approach, and I think we need to, #noestimates offers up some useful ideas. We need to be careful of throwing the entire process out unless we understand the impact. For example, the estimation process is often where a team discusses the story for the first time and starts working toward a READY criteria for a story, part of which is "its small enough to fit into a sprint". If you don't have the estimation process, when will that team collaboration occur? An alternative approach needs to be put in place if we no longer do this through estimation.
@@ Line 23: / Line 23: @@
 ====== Assumption ======
-I've made an assumption here that we are talking team level estimation contributing to an overall release plan. My other thinking on the general subject of estimation is that you use different approaches for different levels of estimation (eg portfolio view vs project view vs team view etc) within an organization. And also, if you are in a multi-team situation, you probably need some level of consistency across teams to report meaningful information and this might influence the overall approach taken (eg you may need to sell ideas you have to other teams)
+I've made an assumption here that we are talking team level estimation contributing to an overall release plan. My other thinking on the general subject of estimation is that you use different approaches for different levels of estimation (eg portfolio view vs project view vs team view etc) within an organization. And also, if you are in a multi-team situation, you probably need some level of consistency across teams to report meaningful information and this might influence the overall approach taken (e.g. you may need to sell ideas you have to other teams)
 ====== Want to Know More? ======