## 24222Re: Why points are lame...

Expand Messages
• Oct 2, 2007
• 0 Attachment
before we get lost in the fray, lets take a step back and ask whether
story points as an estimating technique. If it doesn't then lets try
and address that, rather than half a thread with so much wasted energy
on things that may be irrelevant.

lets assume it does for moment....

estimates will be out, so get used to it. they are supposed to be
accurate based on what you know...precision comes later! Using a range
in estimating is a super way of highlighting that its not intnded to
be precise!

and..

story points are meaningless...they aren't hours or days or anything
that equates to time. They are just numbers to represent a measure of
size (how big is this) and complexity (how hard is this), and to
reflect relative sizing (this is 2ce that!).

In the piles of rock scenario... surely complexity is based on a load
of factors including the tools at hand. So while a front-loader might
get the task done sooner....that is secondary, IMHO primarily it makes
perhaps the story might be better expressed as 'move the pile of rocks
with a front-loader' as opposed to 'move the pile of rocks'.

mike
csm.certified.certifiable.

--- In scrumdevelopment@yahoogroups.com, "Jeff Heinen" <jheinen@...>
wrote:
>
> If the team committing to the story didn't give the original
estimate they should re-estimate it. Estimates do not transfer across
teams.
>
>
>
> -Jeff H.
>
>
>
> From: scrumdevelopment@yahoogroups.com
[mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Clinton Keith
> Sent: Thursday, September 27, 2007 1:53 PM
> To: scrumdevelopment@yahoogroups.com
> Subject: RE: [scrumdevelopment] Why points are lame...
>
>
>
> Analogies are useful because the application details get in the way.
>
>
>
> Yes, both piles of rock will have the same story points because they
are on the same backlog. The points themselves don't matter as much
as the relative points between two stories. E.g. (or exempli gratia
if we want to get all Latin here ;), a pile that is twice the size of
the first should have 2X the story points regardless of which team may
take on the story in a future Sprint. That team may not even exist
when the story points were estimated!
>
>
>
> This illustrates the value of independence of velocity to story
points in Scrum. Teams will self organize to optimize their velocity.
The team with the front loader will take on the gravel stories. The
team with shovels should either not be a part of the project or take
on stories that are more closely matched to their skills.
>
>
>
> Also, teams are not making the same commitment to story points as
they are to Sprint backlog estimates. Often story points are
estimated with a larger group. Commitment comes when the sprint
backlog is created by breaking down the stories into tasks and
estimating the hours there. Note that at this point, the story points
are not used in estimating the sprint backlog.
>
>
>
> I agree with Malcolm. We've been through several large projects
with it. It works. Trying it out will generate much more value than
a huge debate here.
>
>
> Clint
>
>
>
> -----Original Message-----
> From: scrumdevelopment@yahoogroups.com
[mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Roy Morien
> Sent: Thursday, September 27, 2007 11:12 AM
> To: scrumdevelopment@yahoogroups.com
> Subject: RE: [scrumdevelopment] Why points are lame...
>
>
>
> I would like something a little more convincing than a story about
two piles of gravel. I have always thought why use an analogy, when
the real situation will do :)
>
> But let's follow that up anyway. Ok, each pile of gravel is exactly
the same. But the teams know that, on the one hand, they have a
front-end loader, and on the other hand just shovels and muscles. So
would each team, ceterus paribus, still give each pile of gravel (or
the removal task), exactly the same number of story points. One team
knows that it will be a quick and easy job (note ... time and
complexity) and the other team knows that it will be a slow, dirty and
hard job. So again, would each team estimate the same number of story
points? Personally, I think if they did, it would be denying the
reality of their situations, and ignoring the tools and circumstances
available to them.
>
> Regards,
> Roy Morien
>
>
>
> ________________________________
>
> To: scrumdevelopment@yahoogroups.com
> From: ckeith@...
> Date: Thu, 27 Sep 2007 10:35:02 -0700
> Subject: RE: [scrumdevelopment] Why points are lame...
>
> Ø A teams velocity tends to level out over time.
>
>
>
> (To the original thread poster)
>
> While I agree that the velocity becomes more predictable over time,
the continual push to increase the velocity from the team through
retrospectives and improved practices still creates value in
separating points from duration in estimation.
>
>
>
> Additionally, the value of points in complexity, separated from
duration, is valuable when you have multiple teams drawing from the
same backlog. One analogy used is that you might have two piles of
gravel that have to be moved by a team. One team has shovels and the
other a front loader. I doubt both teams would have the same duration.
>
>
>
> Apologies to Mike Cohn for abusing his analogy. ;)
>
>
>
> Clint
>
>
>
> -----Original Message-----
> From: scrumdevelopment@yahoogroups.com
[mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Malcolm Anderson
> Sent: Thursday, September 27, 2007 12:31 AM
> To: scrumdevelopment@yahoogroups.com
> Subject: Re: [scrumdevelopment] Why points are lame...
>
>
>
> I disagree, it *does* all comes down to duration.
>
> Story points do evolve into a useful measure of complexity over time.
> A teams velocity tends to level out over time.
>
> Once you have an idea of how big your project is (total number of
> story points) and how fast you're going (current stable velocity) you
> have a pretty good measure of when you're going to be done, provided
> nothing big changes.
>
> And if something big changes, management is responsible for choosing to
> A) cut features
> B) extend the dead line
> C) kill the project
>
> Story points allow management to honestly evaluate the cost of a given
> requirements change, or the cost of missing a requirements change.
>
> It also prevents them from demanding that 9 women produce a baby in
1 month.
>
> In my book this counts as is a good thing.
>
> Malcolm
>
> On 9/26/07, Nicholas Cancelliere <nickaustin74@...> wrote:
>
> > You're missing the point about story points. It's not about
> >
> >
> > Your example would be more accurate if that second conversation was:
> >
> >
> > SM - "our backlog is 200 hours, based on our current estimates.
Our last sprint we did 50 hours, and so I guess that'll be 4 sprints
of work - assuming nothing changes with the team."
> >
> >
> >
> > PO - "but don't you guys get better the longer you do this stuff
and get more comfortable with the project? maybe we should revisit the
estimates."
> >
>
>
>
>
>
> ________________________________
>