Re: Why points are lame...
I'm hoping you mean consistently mis-estimated in ONE estimating
session and NOT in consecutive product planning sessions. On the off
chance you didn't mean that, here is what I thought:
I'm sure your experience is well informed, but I personally would have
little faith in a team that consistently mis-estimated. It indicates
to me that so many things are wrong.
Estimates ARE supposed to get better with time, the more stuff you do,
the more historicals you have to feed into future estimates. Now if a
team is consistently mis-estimating, then it appears to me that
they're not learning. If they are not learning, what else aren't they
doing. Trust begins to get eroded somewhat when I have to doubt what
else a team isn't doing. This is not good. Its bad.
Part of the reason , I think, that this seems so emotive is that
customers forget that estimates are just that, a guess. Might be
educated, well informed, methodical and the rest, just a guess. Then
somehow, it becomes something that vast amounts of time and money get
spent trying to achieve. Its crazy.
--- In firstname.lastname@example.org, Nicholas Cancelliere
> Accuracy is nice, but consistency is just as good.
> We all know it's difficult to be accurate with estimates, but what we
> can hope for is consistent "mis-estimates." You can still plan a
> project even if the estimates are not as accurate as you wished, so
> long as they're consistently so.
> I don't see how accuracy enters the thread on hours vs story point
> estimates. Both estimates can be equally accurate or not. Neither
> method affords better accuracy by itself, imho.
> The reason I would use story points are in my earlier posts in this
> thread, but basically: a) an easier estimate you can get everyone to
> agree on, b) have long shelf life (don't require a lot of re-estimating)
> On Oct 3, 2007, at 2:31 PM, Malcolm Anderson wrote:
> > Hi Mike
> > I'm going to pick one nit in your otherwise outstanding post.
> > You make the statement, "Remembering that accuracy is the goal." and I
> > have to provisionally disagree with you.
> Nicholas Cancelliere
> Austin, TX
> Got sugu on the brain?
> P Before printing this, think about the environment.
- 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.
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!