- ... Aldo: I agree with Petir. Very often, estimating using real time gives the illusion that you can get a pretty accurate estimate of how long something willMessage 1 of 185 , Sep 30, 2007View SourcePetri Heiramo:
> Based on personal observation on our projects, hour estimates have aAldo:
> tendency to err quite a lot. Yet they give the impression of accuracy
> and validity. Story points don't have such an illusion built into
> them. They accurately reflect the amount of uncertainty in any
> estimate. That alone should be a reason for software developers to use
> them, since so many times estimates are interpreted as commitments to
> certain expense and effort spent.
I agree with Petir. Very often, estimating using real time gives the illusion that you can get a pretty accurate estimate of how long something will take.
However, while time is definate and finite, tasks are undefined and variable. Until one commits to a task, it is very difficult to accurately estimate how long it will take to accomplish. There are many reasons for this including the fact the humans are not machines with a standard output rate, a developer on a task may be called to fix a bug, etc. (see Mary & Tom Poppendieck "Implementing Lean Software Development: From Concept to Cash").
Another reason why developers estimate using story points or as Mike Cohn (i believe it was in his book on Story Estimating and Planning) also calls "Ideal Time" is because humans lack the ability to accurately predict the future (most likely, not even Nostradamus would be able to accurately predict the length of a task :). As Petri said, "[story points] reflect the amount of uncertainty in an estimate". This is also why a 4 point story can take 3 days to implement for one story and 5 days for another.
When teams decompose stories into tasks, they will get a better idea of how long something will take to accomplish in real time given their team's current state. Still, this is not an accurate prediction and can only be based on past experiences, thus the notion of a burn-down chart.
Aldo Cauchi Savona
Uniblue Systems Ltd.
- I think getting into a controversy on whether or not we should have Sprint 0 or -1 or whatever (leading to discussion on Sprint -5 :)) is a bit sophistic.Message 185 of 185 , Nov 24, 2008View SourceI think getting into a controversy on whether or not we should have Sprint 0 or -1 or whatever (leading to discussion on Sprint -5 :)) is a bit sophistic.
Whatever you care to call it, I think it is essential to have it, to ensure that the development team is ready, willing and able to go. To a great extent it is the Envision phase, I think, which includes ensuring that the development team is approproiate to the task, that the whole general picture is understood, that everyone is singing from the same hymn book, getting all the ducks in a row and so on. There has been some discussion in this group previously about whether or not this pre-project phase (that is, pre iteration phase) should include decisions about and the adoption of development tools and standards. Some say this should emerge during later iterations, but I disagree.
Having undertaken this phase, the project team is then able to competently and enthusiastically (one hopes) into the iteration cycle of the project proper.
What Scott Ambler was talking about seems to me to be just this situation.
Sprint 0, Sprint -1, Pre-Project Phase, Envision Phase ... what's in a name, a rose etc .....
Date: Mon, 24 Nov 2008 11:42:54 +0000
Subject: [scrumdevelopment] Re: Sprint Zero
> > what he defines as "iteration -1" and "iteration 0"I have discussed the 'Sprint zero' matter a couple of times. The
> I do hear this kind of thing a lot, but it smells like procrastination
> to me.
> What innovation is next, the 31 day Sprint?
drawbacks seemed higher than the benefits:
- Sprint zero does not produce working code
- Sprint zero takes away the sense of urgency
- Sprint zero leads to a misunderstanding of Scrum
- Sprint zero disappoints stakeholders
Whenever you need to set the stage before you can actually do Scrum,
don't call it a Sprint or iteration. Once you are in a Sprint, you are
doing Scrum - so the first Sprint is supposed to be Sprint One
- deliver working code
- refine backlog items / user stories
- figure out the architecture outline
- make stakeholders happy
My regards to all the poor teams out there who are still in Sprint
Sign up for the Hotmail Road Trip today. Your dream beach house escape for summer!