--- Ron Jeffries <ronjeffries@...> wrote:
> > Story estimates are used by the PO to plan releases (long term
> > planning).
> Long-term planning is risky business for a process focused on
> steering based on the current real situation, as it "calls the shot"
> for those who read the plan, and therefore makes it dangerous for
> the Product Owner to change plans, as it invites questions.
Agreed, yet that (release planning) is still the purpose of story estimates.
I would expect a healthy scrum organizatin to allow the PO to plan without making "inviting questions" become a dangerous thing, but a constructive thing instead. This is probably fodder for a seperate thread, though.
> > Task estimates are used by the dev-team to plan their day-to-day
> > work towards the end of the sprint (short-term planning).
> If a team wanted to do this, then under the principle of self-
> organization, it should be allowed. It would surprise me to find a
> team that found it useful, much less a team who actually wanted to
> do it.
I'd be glad to surprise you, I've worked with several teams that found this very helpful.
This does not mean it is always helpful - I've also worked with teams in situations where the estimates were just pulling them back.
And again, all this is probably irrelevant to the current thread...
> If a team did choose to do it, then one might think that estimates
> should be made during the Sprint, when there is more information,
> rather than at the beginning.
FWIW I agree with you - I find too that this task-level estimation works best when refined day by day throughout the sprint. Just making initial estimates at the sprint planning has some limited benefits, but they wear off quickly if it stops at that point.
I find the initial task estimates help make an educated guess about if a story is too big to fit in a sprint (or heaven forbid, too small), and helps the team flesh out an initial solution and grasp of the PBI's complexity. Again, the value of having this upfront (during sprint planning) is mainly so they can commit/forecast based on their expected capacity for the sprint.
> > None of these are supposed to be used to track actuals (past).
> > They are just tools to help planning ahead (future).
> And yet many teams do compare estimates and actuals. This is usually
> pernicious, because it drives estimates upward.
Agreed. and a sad thing IMHO.
Best wishes, good to correspond again after such a long time.