is_generating_an_estimate_a_waste_of_time
Differences
This shows you the differences between two versions of the page.
Previous revision | |||
— | 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' | ||
+ | |||
+ | So here are some thoughts. | ||
+ | |||
+ | ====== Some Ideas ====== | ||
+ | |||
+ | To me, this is not a simple subject. My first response would be "what problem are you trying to solve with a # | ||
+ | |||
+ | OK, so getting past the base question, I like the thinking behind # | ||
+ | |||
+ | When I first heard about the concept, there was a discussion about "how to forecast delivery of a feature" | ||
+ | |||
+ | 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 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 " | ||
+ | |||
+ | 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, # | ||
+ | |||
+ | Does this make sense? | ||
+ | |||
+ | ====== 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 (e.g. you may need to sell ideas you have to other teams) | ||
+ | |||
+ | ====== Want to Know More? ====== | ||
+ | |||
+ | Some additional reading that might help: | ||
+ | |||
+ | * http:// | ||
+ | * http:// | ||
+ | |||
+ | |||
+ | {{tag> |