Re: [scrumdevelopment] When do "story points" get frozen?
- The power of user stories is how they are estimated and for what context they are used, and that they are separated from sprint planning in terms of hours. They should be done before sprint planning - they need to be done in purity in their own context.
The context is in the realm of the business and product/release planning, not task-level development forecasting. It should be in units that do not even sound like hours (triggers different thought processes and cognitions, veering us way off). It should also be done on gut hunch at the team level in the fashion of individual forcasting in private before sharing with team. This reduces group process loss (psych) and thus less skewed. Finally, the gut hunch if done well can be taught - our "Thin Slicing".There is actually quite a bit of corroborating scientific evidence explaing this.Cheers!
Mark----- Original Message -----From: Arnette, BillSent: Thursday, November 01, 2007 1:47 PMSubject: RE: [scrumdevelopment] When do "story points" get frozen?I understand that you don't want to re-estimate the story points during a sprint. But how about if you esitmate a story for the product backlog thinking you'll do it one way, but then for the sprint, realize that you could do it another way that still meets the story but can be done in half the time? Re-estimate the story during the sprint planning?--Bill Arnette
From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelo pment@yahoogroup s.com] On Behalf Of Ryan Cooper
Sent: Thursday, November 01, 2007 1:28 PM
To: scrumdevelopment@ yahoogroups. com
Subject: Re: [scrumdevelopment] When do "story points" get frozen?
I don't have a good answer to how far ahead of a sprint to "lock down"
your estimates, but I would strongly advise against re-estimating
after starting work on a story.
The predictive power of your velocity exists because you are comparing
'a priori' estimates of features previously completed to 'a priori'
estimates of features to be completed in the future. If you revise an
estimate after starting work on a story, it becomes an 'a posteriori'
estimate. This will make your velocity a more "real" measure of how
much work you did, but will make velocity a less useful predicting
tool (since you can't have a posteriori estimates of work that will be
done in the future)
Mike Cohn covers this idea in more depth here:
http://blog. mountaingoatsoft ware.com/ ?p=13
On Nov 1, 2007 2:17 PM, Sam Roberts <sroberts@uniserve. com> wrote:
> What about if half-way through the sprint we realize that something we
> thought would be a few days work and worth a few points can be done in a
> few hours? Won't counting this as many points distory the accuracy of
> the velocity measurement?
> To Post a message, send it to: scrumdevelopment@ eGroups.com
> To Unsubscribe, send a blank message to: scrumdevelopment- unsubscribe@ eGroups.com
> Yahoo! Groups Links
- On 11/1/07, Arnette, Bill <billa@...> wrote:
> I understand that you don't want to re-estimate the story points during a sprint. But howNo problem to re-estimate during the sprint planning. It happens all
> about if you esitmate a story for the product backlog thinking you'll do it one way, but then
> for the sprint, realize that you could do it another way that still meets the story but can be
> done in half the time? Re-estimate the story during the sprint planning?
the time as a PO clarifies user stories and negotiates the sprint
When the sprint planning is over, the sprint backlog has been
committed to and the sprint has started, that is the moment to freeze
your story point estimates, for reasons already pointed out (estimates
become less valuable for predictions if adjusted with knowledge not
normally known during the estimation process).
Martin Schapendonk, martin@...