Re: Why points are lame...
- --- In email@example.com, "macdonald1976"
>Points are intended to give a relative measure of size for stories,
> First of all, anything you can make up your own definition for is lame
> and suspect to say the least. My CTO doesn't care to hear that my dev
> team has 150 story points left. He wants to know how many hours they
> have left. Hours are not subject to opinion. There are 60 minutes in
> a hour and 24 hours in a day. My CTO can relate to this. My CTO
> cannot relate to some story point with weights assigned arbitrarily
> assigned. Sure, some of you will argue that it is not arbitrary and
> you are entitled to your opinion just like you are entitled to your
> opinion as to what constitutes a point. This opinion on a unit of
> measure and the unscientific approach to defining it, no matter how
> scientific you contend it is, is the reason it has no value in
> defining remaining effort. Points = opinion and like the old saying
> goes, 'opinions are like butt holes, everyone has one'.
not a valid estimate of duration. Mike Cohn (author of Agile
Estimating and Planning) says: "Estimate Size; Derive Duration". The
rationale is that it's much more likely that a team can agree on the
relative amount of work for a story compare to another, than on how
many hours it'll take to implement it.
Compare with two people running a track; The first person will insist
it's a ten minute track, the other a five minute one. Who's right?
They are much more likely to agree that it's a one mile track (or
whatever one can run in five minutes, I honestly have no clue), and
that a two mile track is twice as long. Any two people running the
track are likely to get a different time, but it's still the same size.
So, estimate in points, validate how many points you can complete in
an iteration, using an average over a number of iterations, or
historical numbers if you've got them, and use that to derive the
total project duration. I.e. our velocity of the last three iterations
was 27, then the remaining 189 points could be finished in 7
iterations. You do need to add a range though. Or to quote "It's
better to be roughly right, than precisely wrong". If you've got an
experienced team on a known domain, you may want to adjust the
estimate -10/+5%, if it's a fresh team learning a new domain the
figure might be -50/+25%. (Values from Mike's book) Using the first
figure that gives us a velocity of between 24-28 meaning our 189
points could be done in between 7 and 8 iterations. The inexperienced
newbie team would get an initial estimate of between 6 and 14
iterations. (It's probably not likely that an inexperienced team would
average the same initial velocity as the experienced team, but let's
ignore that for this exercise, the issue here is the range) There's
really no way to know very early in a project. Experience will tighten
the range as the project moves along. So your estimate may narrow from
"1st quarter" to "February" to "Last week of February", all the time
giving the Product Owner an accurate estimate, just not a precise one.
Something you shouldn't do, however, is to try to transform the hours
of your completed iterations back onto the remaining stories.
Estimates are pretty much bound to follow the normal distribution and
thus you'll end up with "easy" fives and "hard" fives. Imagine the
disappointment if you end up spending 76 hours on an "easy" five from
your first iteration and then apply it to every five point story in
the backlog. It just won't work and you're back at trying to estimate
Also, there's no promise that ten points for one team can be related
to ten points for another. It's just a number, that makes sense to
that particular team, and the CEO should not care about its meaning in
relation to duration or any other unit. It's a unit-less relative
measure of size for a given team. Period.
So, you give your boss the date range, derived above, not the points
themselves. The points are to be used by the PO to prioritize stories
along with estimated ROI and any other factors that may contribute.
I absolutely recommend Mike's book if you're interested in a more
in-depth explanation of the above thoughts.
- 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!