## Re: Conservation of Size Points, AKA: Partial Credit for Backlogs

Expand Messages
• We elected b , and it worked fine. Sure, you don t get a true velocity, but velocity itself is a means to an end, not the goal of using story points. I
Message 1 of 17 , Apr 1, 2009
We elected 'b', and it worked fine. Sure, you don't get a "true" velocity, but velocity itself is a means to an end, not the goal of using story points.

I found it better to use a rolling average (3 iterations) when calculating velocity. In general, there was always stories that weren't quite finished, and were credited in the next iteration. Also, using a rolling average helps smooth out the hills and valleys, and IMHO, gives a more accurate measure of the speed of the team.

Mark

--- In scrumdevelopment@yahoogroups.com, "steveteske" <steveteske@...> wrote:
>
> We are having a lively debate about Size Points. I am calling the "Conservation of Size Points Debate", because the following practices of your SCRUM Masters:
>
> Either a) If you don't finish a backlog item, estimate the remaining size of the backlog and assign it to the next sprint, giving partial credit to the failing sprint (thus preserving the overall size points)
>
> or b) If you don't finish a backlog item, give yourself zero credit in the failing sprint and carry over the size points (without reduction) to the next sprint. When you actual finish the backlog, you get count credit for in the sprint in which it is finished...but it's full credit from the original size points (don't reduce).
>
> Mathematically these two paradigms result in EXACTLY the same velocity calculation.
>
> Here's my dilema: I think the math above does not reflect true velocity. I don't have a palatable explanation of why partial credit schemes will fail to delivery the correct velocity measurement. But the harder isssue is the politics of counting instantaneous velocity (counting only the things that are DONE) and discarding the size points of partially completed work appears to reduce the overall backlog size. It appears that size points are disappearing if I count only the "Done" work. While I believe this promotes a better understanding of TRUE velocity, the politics and the Math of what I call non-conservation of size points is apparently either my misunderstanding of SCRUM or it's a bridge too far for my director to sell to Project Management because in non-conservation of size points, it looks like size points are mysteriously disappearing.
>
> I don't have a problem with disappearing size points because according to my math, if I have TRUE velocity and the total size points to the next release, I've got what I need.
>
> I am not sure how to deal with conservation vs. non-conservation of size points.
>
> Help would be appreciated.
>
> Steve Teske
> Thales Communications Inc., Clarksburg, MD
>
• I agree with you, Mark. I am not sure if the overhead of splitting stories and then calculating the balance is worth the effort. Its easier to communicate the
Message 2 of 17 , Apr 1, 2009
I agree with you, Mark. I am not sure if the overhead of splitting
stories and then calculating the balance is worth the effort. Its easier
to communicate the progress for even those stories not done using words
than numbers.

Jayanthan

woynam wrote:
>
>
> We elected 'b', and it worked fine. Sure, you don't get a "true"
> velocity, but velocity itself is a means to an end, not the goal of
> using story points.
>
> I found it better to use a rolling average (3 iterations) when
> calculating velocity. In general, there was always stories that
> weren't quite finished, and were credited in the next iteration. Also,
> using a rolling average helps smooth out the hills and valleys, and
> IMHO, gives a more accurate measure of the speed of the team.
>
> Mark
>
> --- In scrumdevelopment@yahoogroups.com
> <mailto:scrumdevelopment%40yahoogroups.com>, "steveteske"
> <steveteske@...> wrote:
> >
> > We are having a lively debate about Size Points. I am calling the
> "Conservation of Size Points Debate", because the following practices
> >
> > Either a) If you don't finish a backlog item, estimate the remaining
> size of the backlog and assign it to the next sprint, giving partial
> credit to the failing sprint (thus preserving the overall size points)
> >
> > or b) If you don't finish a backlog item, give yourself zero credit
> in the failing sprint and carry over the size points (without
> reduction) to the next sprint. When you actual finish the backlog, you
> get count credit for in the sprint in which it is finished...but it's
> full credit from the original size points (don't reduce).
> >
> > Mathematically these two paradigms result in EXACTLY the same
> velocity calculation.
> >
> > Here's my dilema: I think the math above does not reflect true
> velocity. I don't have a palatable explanation of why partial credit
> schemes will fail to delivery the correct velocity measurement. But
> the harder isssue is the politics of counting instantaneous velocity
> (counting only the things that are DONE) and discarding the size
> points of partially completed work appears to reduce the overall
> backlog size. It appears that size points are disappearing if I count
> only the "Done" work. While I believe this promotes a better
> understanding of TRUE velocity, the politics and the Math of what I
> call non-conservation of size points is apparently either my
> misunderstanding of SCRUM or it's a bridge too far for my director to
> sell to Project Management because in non-conservation of size points,
> it looks like size points are mysteriously disappearing.
> >
> > I don't have a problem with disappearing size points because
> according to my math, if I have TRUE velocity and the total size
> points to the next release, I've got what I need.
> >
> > I am not sure how to deal with conservation vs. non-conservation of
> size points.
> >
> > Help would be appreciated.
> >
> > Steve Teske
> > Thales Communications Inc., Clarksburg, MD
> >
>
>
• Then why do all this work and then cop out at the end. Stay with conventional practices folks. We need people with this kind of thinking to not consider
Message 3 of 17 , Apr 1, 2009
Then why do all this work and then cop out at the end. Stay with conventional practices folks. We need people with this kind of thinking to not consider themselves part of this community.
Agile and Scrum are about done. AIG and other loser approaches about rewarding whining and in doing so ripping off this country and this world.
Yes it hard work and not much fun. Most of all you have to lose to be successful. That is a lot better than what you are suggesting.

Sent via BlackBerry by AT&T

Date: Wed, 01 Apr 2009 12:36:00 -0400
To: <scrumdevelopment@yahoogroups.com>
Subject: Re: [scrumdevelopment] Re: Conservation of Size Points, AKA: Partial Credit for Backlogs

I agree with you, Mark. I am not sure if the overhead of splitting
stories and then calculating the balance is worth the effort. Its easier
to communicate the progress for even those stories not done using words
than numbers.

Jayanthan

woynam wrote:

>
>
> We elected 'b', and it worked fine. Sure, you don't get a "true"
> velocity, but velocity itself is a means to an end, not the goal of
> using story points.
>
> I found it better to use a rolling average (3 iterations) when
> calculating velocity. In general, there was always stories that
> weren't quite finished, and were credited in the next iteration. Also,
> using a rolling average helps smooth out the hills and valleys, and
> IMHO, gives a more accurate measure of the speed of the team.
>
> Mark
>
> --- In scrumdevelopment@ yahoogroups. com
> <mailto:scrumdevelo pment%40yahoogro ups.com>, "steveteske"
> <steveteske@ ...> wrote:
> >
> > We are having a lively debate about Size Points. I am calling the
> "Conservation of Size Points Debate", because the following practices
> >
> > Either a) If you don't finish a backlog item, estimate the remaining
> size of the backlog and assign it to the next sprint, giving partial
> credit to the failing sprint (thus preserving the overall size points)
> >
> > or b) If you don't finish a backlog item, give yourself zero credit
> in the failing sprint and carry over the size points (without
> reduction) to the next sprint. When you actual finish the backlog, you
> get count credit for in the sprint in which it is finished...but it's
> full credit from the original size points (don't reduce).
> >
> > Mathematically these two paradigms result in EXACTLY the same
> velocity calculation.
> >
> > Here's my dilema: I think the math above does not reflect true
> velocity. I don't have a palatable explanation of why partial credit
> schemes will fail to delivery the correct velocity measurement. But
> the harder isssue is the politics of counting instantaneous velocity
> (counting only the things that are DONE) and discarding the size
> points of partially completed work appears to reduce the overall
> backlog size. It appears that size points are disappearing if I count
> only the "Done" work. While I believe this promotes a better
> understanding of TRUE velocity, the politics and the Math of what I
> call non-conservation of size points is apparently either my
> misunderstanding of SCRUM or it's a bridge too far for my director to
> sell to Project Management because in non-conservation of size points,
> it looks like size points are mysteriously disappearing.
> >
> > I don't have a problem with disappearing size points because
> according to my math, if I have TRUE velocity and the total size
> points to the next release, I've got what I need.
> >
> > I am not sure how to deal with conservation vs. non-conservation of
> size points.
> >
> > Help would be appreciated.
> >
> > Steve Teske
> > Thales Communications Inc., Clarksburg, MD
> >
>
>

• Mike, what on earth are you talking about? I have no idea if you agree or disagree with our comments. Mark
Message 4 of 17 , Apr 1, 2009
Mike, what on earth are you talking about? I have no idea if you agree or disagree with our comments.

Mark

--- In scrumdevelopment@yahoogroups.com, mike.dwyer1@... wrote:
>
> Then why do all this work and then cop out at the end. Stay with conventional practices folks. We need people with this kind of thinking to not consider themselves part of this community.
> Agile and Scrum are about done. AIG and other loser approaches about rewarding whining and in doing so ripping off this country and this world.
> Yes it hard work and not much fun. Most of all you have to lose to be successful. That is a lot better than what you are suggesting.
>
>
> Sent via BlackBerry by AT&T
>
> -----Original Message-----
>
> Date: Wed, 01 Apr 2009 12:36:00
> To: <scrumdevelopment@yahoogroups.com>
> Subject: Re: [scrumdevelopment] Re: Conservation of Size Points, AKA: Partial
> Credit for Backlogs
>
>
> I agree with you, Mark. I am not sure if the overhead of splitting
> stories and then calculating the balance is worth the effort. Its easier
> to communicate the progress for even those stories not done using words
> than numbers.
>
> Jayanthan
>
> woynam wrote:
> >
> >
> > We elected 'b', and it worked fine. Sure, you don't get a "true"
> > velocity, but velocity itself is a means to an end, not the goal of
> > using story points.
> >
> > I found it better to use a rolling average (3 iterations) when
> > calculating velocity. In general, there was always stories that
> > weren't quite finished, and were credited in the next iteration. Also,
> > using a rolling average helps smooth out the hills and valleys, and
> > IMHO, gives a more accurate measure of the speed of the team.
> >
> > Mark
> >
> > --- In scrumdevelopment@yahoogroups.com
> > <mailto:scrumdevelopment%40yahoogroups.com>, "steveteske"
> > <steveteske@> wrote:
> > >
> > > We are having a lively debate about Size Points. I am calling the
> > "Conservation of Size Points Debate", because the following practices
> > of your SCRUM Masters:
> > >
> > > Either a) If you don't finish a backlog item, estimate the remaining
> > size of the backlog and assign it to the next sprint, giving partial
> > credit to the failing sprint (thus preserving the overall size points)
> > >
> > > or b) If you don't finish a backlog item, give yourself zero credit
> > in the failing sprint and carry over the size points (without
> > reduction) to the next sprint. When you actual finish the backlog, you
> > get count credit for in the sprint in which it is finished...but it's
> > full credit from the original size points (don't reduce).
> > >
> > > Mathematically these two paradigms result in EXACTLY the same
> > velocity calculation.
> > >
> > > Here's my dilema: I think the math above does not reflect true
> > velocity. I don't have a palatable explanation of why partial credit
> > schemes will fail to delivery the correct velocity measurement. But
> > the harder isssue is the politics of counting instantaneous velocity
> > (counting only the things that are DONE) and discarding the size
> > points of partially completed work appears to reduce the overall
> > backlog size. It appears that size points are disappearing if I count
> > only the "Done" work. While I believe this promotes a better
> > understanding of TRUE velocity, the politics and the Math of what I
> > call non-conservation of size points is apparently either my
> > misunderstanding of SCRUM or it's a bridge too far for my director to
> > sell to Project Management because in non-conservation of size points,
> > it looks like size points are mysteriously disappearing.
> > >
> > > I don't have a problem with disappearing size points because
> > according to my math, if I have TRUE velocity and the total size
> > points to the next release, I've got what I need.
> > >
> > > I am not sure how to deal with conservation vs. non-conservation of
> > size points.
> > >
> > > Help would be appreciated.
> > >
> > > Steve Teske
> > > Thales Communications Inc., Clarksburg, MD
> > >
> >
> >
>
• ... Right. What some, including myself, have advocated is that you size up the remaining work and give zero credit for work in the current iteration that was
Message 5 of 17 , Apr 1, 2009
On Tue, Mar 31, 2009 at 6:39 PM, steveteske <steveteske@...> wrote:
> We are having a lively debate about Size Points. I am calling the
> "Conservation of Size Points Debate", because the following practices of
>
> Either a) If you don't finish a backlog item, estimate the remaining size of
> the backlog and assign it to the next sprint, giving partial credit to the
> failing sprint (thus preserving the overall size points)
>
> or b) If you don't finish a backlog item, give yourself zero credit in the
> failing sprint and carry over the size points (without reduction) to the
> next sprint. When you actual finish the backlog, you get count credit for in
> the sprint in which it is finished...but it's full credit from the original
> size points (don't reduce).
>
> Mathematically these two paradigms result in EXACTLY the same velocity
> calculation.
>
> Here's my dilema: I think the math above does not reflect true velocity. I
> don't have a palatable explanation of why partial credit schemes will fail
> to delivery the correct velocity measurement.

Right. What some, including myself, have advocated is that you size up
the remaining work and give zero credit for work in the current
iteration that was not completed. In this way you somewhat
underestimate the actual effort that was expended, but you account for
the fact that some of that effort was wasted (in the sense that
whatever was produced was not deliverable at the end of the
iteration.)

This is not conservative of points. Points are arbitrary by
definition. So, not conserving them doesn't hurt me one bit.

This approach makes all kinds of sense to me. I am a musician. Also, I
practice martial arts. In both of those avocations we strive to
perform accurately and fast. In order to go fast we have to push
ourselves. There will always be a speed that is too fast for us to
perform accurately. So, we slow down to the point where we are
accurate again and gradually increase our speed.

What I am saying is that missing a story is like missing a note. The
correct response is to slow down and stop missing them. Then speed up
again.

But the harder isssue is the
> politics of counting instantaneous velocity (counting only the things that
> are DONE) and discarding the size points of partially completed work appears
> to reduce the overall backlog size. It appears that size points are
> disappearing if I count only the "Done" work. While I believe this promotes
> a better understanding of TRUE velocity, the politics and the Math of what I
> call non-conservation of size points is apparently either my
> misunderstanding of SCRUM or it's a bridge too far for my director to sell
> to Project Management because in non-conservation of size points, it looks
> like size points are mysteriously disappearing.
>
> I don't have a problem with disappearing size points because according to my
> math, if I have TRUE velocity and the total size points to the next release,
> I've got what I need.
>
> I am not sure how to deal with conservation vs. non-conservation of size
> points.
>

I would tell them that the missing points represent waste. Effort was
expended that did not result in any story being delivered and that
effort does not count. The re-estimate of the story accounts for the
amount of effort it will take to recoup that loss. Since you aren't
going to redo anything you already did, the new cost is not as high.

I would also point out that story points are arbitrary and there is no
reason to believe that they are conservative. If that doesn't go over,
I would point out that effort is conservative in the same way that
energy is: we know that the sum of the energy in equals the sum of the
energy out. We also know that only a portion (Often a very small
portion) of that energy produces work. Our velocity in Scrum is a
measure of the work we produced in the iteration, not of the total
effort that went in.

In other words:

Total Effort = Effort that produced running tested software + Waste

Velocity = Effort that produced running tested software *during the iteration*
• I took this to be a 4/1 post. Sorry But since you are serious on this, let s ask some simple questions. Is this preoccupation with the math of story points
Message 6 of 17 , Apr 1, 2009
I took this to be a 4/1 post. Sorry

But since you are serious on this, let's ask some simple questions.
Is this preoccupation with the math of story points clouding the actual value they bring? Keep in mind that velocity is nothing more than a regression to the mean and since we choose not to keep teams together long enough for it to have any statistical relevance. If your projects are over in 6 - 12 months 8 - 24 samples are useless in a linear regression. Now if we want to think in trends that is another story and another slope to slide on.
But trends are estimates and that is it they don't go any where else

So what can a story sizing do? Hmm create a collaborative and self correcting map of the capability to deliver value. If you suck at doing that then you need to find this out and do something about.
Focusing on giving yourself credit doesn't make that happen. Try spending time on why you can't estimate

Sent via BlackBerry by AT&T

From: "woynam"
Date: Wed, 01 Apr 2009 20:03:47 -0000
To: <scrumdevelopment@yahoogroups.com>
Subject: [scrumdevelopment] Re: Conservation of Size Points, AKA: PartialCredit for Backlogs

Mike, what on earth are you talking about? I have no idea if you agree or disagree with our comments.

Mark

--- In scrumdevelopment@ yahoogroups. com, mike.dwyer1@ ... wrote:
>
> Then why do all this work and then cop out at the end. Stay with conventional practices folks. We need people with this kind of thinking to not consider themselves part of this community.
> Agile and Scrum are about done. AIG and other loser approaches about rewarding whining and in doing so ripping off this country and this world.
> Yes it hard work and not much fun. Most of all you have to lose to be successful. That is a lot better than what you are suggesting.
>
>
> Sent via BlackBerry by AT&T
>
> -----Original Message-----
>
> Date: Wed, 01 Apr 2009 12:36:00
> To: <scrumdevelopment@ yahoogroups. com>
> Subject: Re: [scrumdevelopment] Re: Conservation of Size Points, AKA: Partial
> Credit for Backlogs
>
>
> I agree with you, Mark. I am not sure if the overhead of splitting
> stories and then calculating the balance is worth the effort. Its easier
> to communicate the progress for even those stories not done using words
> than numbers.
>
> Jayanthan
>
> woynam wrote:
> >
> >
> > We elected 'b', and it worked fine. Sure, you don't get a "true"
> > velocity, but velocity itself is a means to an end, not the goal of
> > using story points.
> >
> > I found it better to use a rolling average (3 iterations) when
> > calculating velocity. In general, there was always stories that
> > weren't quite finished, and were credited in the next iteration. Also,
> > using a rolling average helps smooth out the hills and valleys, and
> > IMHO, gives a more accurate measure of the speed of the team.
> >
> > Mark
> >
> > --- In scrumdevelopment@ yahoogroups. com
> > <mailto:scrumdevelo pment%40yahoogro ups.com>, "steveteske"
> > <steveteske@ > wrote:
> > >
> > > We are having a lively debate about Size Points. I am calling the
> > "Conservation of Size Points Debate", because the following practices
> > of your SCRUM Masters:
> > >
> > > Either a) If you don't finish a backlog item, estimate the remaining
> > size of the backlog and assign it to the next sprint, giving partial
> > credit to the failing sprint (thus preserving the overall size points)
> > >
> > > or b) If you don't finish a backlog item, give yourself zero credit
> > in the failing sprint and carry over the size points (without
> > reduction) to the next sprint. When you actual finish the backlog, you
> > get count credit for in the sprint in which it is finished...but it's
> > full credit from the original size points (don't reduce).
> > >
> > > Mathematically these two paradigms result in EXACTLY the same
> > velocity calculation.
> > >
> > > Here's my dilema: I think the math above does not reflect true
> > velocity. I don't have a palatable explanation of why partial credit
> > schemes will fail to delivery the correct velocity measurement. But
> > the harder isssue is the politics of counting instantaneous velocity
> > (counting only the things that are DONE) and discarding the size
> > points of partially completed work appears to reduce the overall
> > backlog size. It appears that size points are disappearing if I count
> > only the "Done" work. While I believe this promotes a better
> > understanding of TRUE velocity, the politics and the Math of what I
> > call non-conservation of size points is apparently either my
> > misunderstanding of SCRUM or it's a bridge too far for my director to
> > sell to Project Management because in non-conservation of size points,
> > it looks like size points are mysteriously disappearing.
> > >
> > > I don't have a problem with disappearing size points because
> > according to my math, if I have TRUE velocity and the total size
> > points to the next release, I've got what I need.
> > >
> > > I am not sure how to deal with conservation vs. non-conservation of
> > size points.
> > >
> > > Help would be appreciated.
> > >
> > > Steve Teske
> > > Thales Communications Inc., Clarksburg, MD
> > >
> >
> >
>

• ... Steve, I was traveling yesterday and see you ve already received a lot of good replies. I d like to approach this in a slightly different fashion, though
Message 7 of 17 , Apr 2, 2009
Steve Teske wrote:
> We are having a lively debate about Size Points...
>
> ...giving partial
> credit to the failing sprint
>
> ...give yourself zero credit
> in the failing sprint and carry over...
> ...full credit from the original size points (don't reduce).
>
> Mathematically these two paradigms result in EXACTLY the same
> velocity calculation.
>
> Here's my dilema: I think the math above does not reflect true
> velocity. I don't have a palatable explanation of why partial credit
> schemes will fail to delivery the correct velocity measurement. But
> the harder isssue is the politics of counting instantaneous velocity
> (counting only the things that are DONE) and discarding the size
> points of partially completed work appears to reduce the overall
> backlog size. It appears that size points are disappearing if I
> count only the "Done" work. While I believe this promotes a better
> understanding of TRUE velocity, the politics and the Math of what I
> call non-conservation of size points is apparently either my
> misunderstanding of SCRUM or it's a bridge too far for my director to
> sell to Project Management because in non-conservation of size
> points, it looks like size points are mysteriously disappearing.

Steve, I was traveling yesterday and see you've already received a lot
of good replies. I'd like to approach this in a slightly different
fashion, though others have hinted in this direction.

Why does your organization give so much importance to story points? Why
do you think they're a credit to the team? Why does your Project
Management think they're something to put in the bank?

What is your goal? To produce valuable, working software? Or to
collect story points?

Why do you use story points? To measure the worth of the team? Or to
help the team select approximately the right amount of work for the next
iteration?

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
• You seem to be trying to make a mathematical science out of a simple concept used for a simple purpose. The complexity about story points is being able to
Message 8 of 17 , Apr 2, 2009
You seem to be trying to make a mathematical science out of a simple concept used for a simple purpose. The complexity about story points is being able to first decide on your scale, and then assessing user stories for their story point value.That takes experience and gut feeling, frankly. Even if you get awfully good at it, it is still only indicative and approximate.

If you try to use story points for any other reason (which is to estimate story complexity and probable effort , and apply that to an estimate of probable completion dates) then you will introduce a whole raft of nonsense and 'cheating' into it. Eg, if a manager starts to compare across teams based on story points achieved, then, simple solution to stay ahead of the other team, move your scale up ... what was a 4 point story is now an 8 point story, on no other grounds but you have changed your scale.

I see this aas yet another outside cause of why agile methods 'fail', not for any intrinsic weakness or problem in the method, but because of outside misuse and misunderstanding.

Regards,
Roy Morien

To: scrumdevelopment@yahoogroups.com
From: lists@...
Date: Thu, 2 Apr 2009 08:00:55 -0400
Subject: Re: [scrumdevelopment] Conservation of Size Points, AKA: Partial Credit for Backlogs

Steve Teske wrote:
> We are having a lively debate about Size Points...
>
> ...giving partial
> credit to the failing sprint
>
> ...give yourself zero credit
> in the failing sprint and carry over...
> ...full credit from the original size points (don't reduce).
>
> Mathematically these two paradigms result in EXACTLY the same
> velocity calculation.
>
> Here's my dilema: I think the math above does not reflect true
> velocity. I don't have a palatable explanation of why partial credit
> schemes will fail to delivery the correct velocity measurement. But
> the harder isssue is the politics of counting instantaneous velocity
> (counting only the things that are DONE) and discarding the size
> points of partially completed work appears to reduce the overall
> backlog size. It appears that size points are disappearing if I
> count only the "Done" work. While I believe this promotes a better
> understanding of TRUE velocity, the politics and the Math of what I
> call non-conservation of size points is apparently either my
> misunderstanding of SCRUM or it's a bridge too far for my director to
> sell to Project Management because in non-conservation of size
> points, it looks like size points are mysteriously disappearing.

Steve, I was traveling yesterday and see you've already received a lot
of good replies. I'd like to approach this in a slightly different
fashion, though others have hinted in this direction.

Why does your organization give so much importance to story points? Why
do you think they're a credit to the team? Why does your Project
Management think they're something to put in the bank?

What is your goal? To produce valuable, working software? Or to
collect story points?

Why do you use story points? To measure the worth of the team? Or to
help the team select approximately the right amount of work for the next
iteration?

- George

--
------------ --------- --------- --------- --------- --------- -
* George Dinwiddie * http://blog. gdinwiddie. com
Software Development http://www.idiacomp uting.com
Consultant and Coach http://www.agilemar yland.org
------------ --------- --------- --------- --------- --------- -

Find car news, reviews and more Looking to change your car this year?
• That s better. :-) Yes, I agree. We spend too much time worrying about estimation and the math surrounding stories. All this effort doesn t do a thing to
Message 9 of 17 , Apr 2, 2009
That's better. :-)

Yes, I agree. We spend too much time worrying about estimation and the math surrounding stories. All this effort doesn't do a thing to improve the team's ability to deliver stories. Whether we get credit for 5 out of 10 points, or 9 out of 10, doesn't change the fact that one 5 point story is ready for production.

My point was that averaging velocity across (n) Sprints smooths out the rough spots, and gives a fairly accurate measure of the team's velocity without micro-managing the numbers.

I've posted our burn-up chart in the files section from our most recent large project (30+ iterations). The chart has a bar for velocity (3 month average), and you can see it doesn't vary all that much. The team got done what the team got done. Our velocity improved only when we address engineering practices and removed impediments. Our velocity didn't change because we got better at managing the numbers.

Mark

--- In scrumdevelopment@yahoogroups.com, mike.dwyer1@... wrote:
>
> I took this to be a 4/1 post. Sorry
>
> But since you are serious on this, let's ask some simple questions.
> Is this preoccupation with the math of story points clouding the actual value they bring? Keep in mind that velocity is nothing more than a regression to the mean and since we choose not to keep teams together long enough for it to have any statistical relevance. If your projects are over in 6 - 12 months 8 - 24 samples are useless in a linear regression. Now if we want to think in trends that is another story and another slope to slide on.
> But trends are estimates and that is it they don't go any where else
>
> So what can a story sizing do? Hmm create a collaborative and self correcting map of the capability to deliver value. If you suck at doing that then you need to find this out and do something about.
> Focusing on giving yourself credit doesn't make that happen. Try spending time on why you can't estimate
> Sent via BlackBerry by AT&T
>
> -----Original Message-----
> From: "woynam" <woyna@...>
>
> Date: Wed, 01 Apr 2009 20:03:47
> To: <scrumdevelopment@yahoogroups.com>
> Subject: [scrumdevelopment] Re: Conservation of Size Points, AKA: PartialCredit for Backlogs
>
>
>
> Mike, what on earth are you talking about? I have no idea if you agree or disagree with our comments.
>
> Mark
>
> --- In scrumdevelopment@yahoogroups.com, mike.dwyer1@ wrote:
> >
> > Then why do all this work and then cop out at the end. Stay with conventional practices folks. We need people with this kind of thinking to not consider themselves part of this community.
> > Agile and Scrum are about done. AIG and other loser approaches about rewarding whining and in doing so ripping off this country and this world.
> > Yes it hard work and not much fun. Most of all you have to lose to be successful. That is a lot better than what you are suggesting.
> >
> >
> > Sent via BlackBerry by AT&T
> >
> > -----Original Message-----
> > From: Jayanthan Bhattathiripad <jynthn@>
> >
> > Date: Wed, 01 Apr 2009 12:36:00
> > To: <scrumdevelopment@yahoogroups.com>
> > Subject: Re: [scrumdevelopment] Re: Conservation of Size Points, AKA: Partial
> > Credit for Backlogs
> >
> >
> > I agree with you, Mark. I am not sure if the overhead of splitting
> > stories and then calculating the balance is worth the effort. Its easier
> > to communicate the progress for even those stories not done using words
> > than numbers.
> >
> > Jayanthan
> >
> > woynam wrote:
> > >
> > >
> > > We elected 'b', and it worked fine. Sure, you don't get a "true"
> > > velocity, but velocity itself is a means to an end, not the goal of
> > > using story points.
> > >
> > > I found it better to use a rolling average (3 iterations) when
> > > calculating velocity. In general, there was always stories that
> > > weren't quite finished, and were credited in the next iteration. Also,
> > > using a rolling average helps smooth out the hills and valleys, and
> > > IMHO, gives a more accurate measure of the speed of the team.
> > >
> > > Mark
> > >
> > > --- In scrumdevelopment@yahoogroups.com
> > > <mailto:scrumdevelopment%40yahoogroups.com>, "steveteske"
> > > <steveteske@> wrote:
> > > >
> > > > We are having a lively debate about Size Points. I am calling the
> > > "Conservation of Size Points Debate", because the following practices
> > > of your SCRUM Masters:
> > > >
> > > > Either a) If you don't finish a backlog item, estimate the remaining
> > > size of the backlog and assign it to the next sprint, giving partial
> > > credit to the failing sprint (thus preserving the overall size points)
> > > >
> > > > or b) If you don't finish a backlog item, give yourself zero credit
> > > in the failing sprint and carry over the size points (without
> > > reduction) to the next sprint. When you actual finish the backlog, you
> > > get count credit for in the sprint in which it is finished...but it's
> > > full credit from the original size points (don't reduce).
> > > >
> > > > Mathematically these two paradigms result in EXACTLY the same
> > > velocity calculation.
> > > >
> > > > Here's my dilema: I think the math above does not reflect true
> > > velocity. I don't have a palatable explanation of why partial credit
> > > schemes will fail to delivery the correct velocity measurement. But
> > > the harder isssue is the politics of counting instantaneous velocity
> > > (counting only the things that are DONE) and discarding the size
> > > points of partially completed work appears to reduce the overall
> > > backlog size. It appears that size points are disappearing if I count
> > > only the "Done" work. While I believe this promotes a better
> > > understanding of TRUE velocity, the politics and the Math of what I
> > > call non-conservation of size points is apparently either my
> > > misunderstanding of SCRUM or it's a bridge too far for my director to
> > > sell to Project Management because in non-conservation of size points,
> > > it looks like size points are mysteriously disappearing.
> > > >
> > > > I don't have a problem with disappearing size points because
> > > according to my math, if I have TRUE velocity and the total size
> > > points to the next release, I've got what I need.
> > > >
> > > > I am not sure how to deal with conservation vs. non-conservation of
> > > size points.
> > > >
> > > > Help would be appreciated.
> > > >
> > > > Steve Teske
> > > > Thales Communications Inc., Clarksburg, MD
> > > >
> > >
> > >
> >
>
• George A favor to ask. Can you lead with your response? I am living on a BB these days and my thumb is sore from scrolling to the bottom. Sent via BlackBerry
Message 10 of 17 , Apr 2, 2009
George
A favor to ask. Can you lead with your response? I am living on a BB these days and my thumb is sore from scrolling to the bottom.

Sent via BlackBerry by AT&T

From: George Dinwiddie
Date: Thu, 02 Apr 2009 08:00:55 -0400
To: <scrumdevelopment@yahoogroups.com>
Subject: Re: [scrumdevelopment] Conservation of Size Points, AKA: Partial Credit for Backlogs

Steve Teske wrote:

> We are having a lively debate about Size Points...
>
> ...giving partial
> credit to the failing sprint
>
> ...give yourself zero credit
> in the failing sprint and carry over...
> ...full credit from the original size points (don't reduce).
>
> Mathematically these two paradigms result in EXACTLY the same
> velocity calculation.
>
> Here's my dilema: I think the math above does not reflect true
> velocity. I don't have a palatable explanation of why partial credit
> schemes will fail to delivery the correct velocity measurement. But
> the harder isssue is the politics of counting instantaneous velocity
> (counting only the things that are DONE) and discarding the size
> points of partially completed work appears to reduce the overall
> backlog size. It appears that size points are disappearing if I
> count only the "Done" work. While I believe this promotes a better
> understanding of TRUE velocity, the politics and the Math of what I
> call non-conservation of size points is apparently either my
> misunderstanding of SCRUM or it's a bridge too far for my director to
> sell to Project Management because in non-conservation of size
> points, it looks like size points are mysteriously disappearing.

Steve, I was traveling yesterday and see you've already received a lot
of good replies. I'd like to approach this in a slightly different
fashion, though others have hinted in this direction.

Why does your organization give so much importance to story points? Why
do you think they're a credit to the team? Why does your Project
Management think they're something to put in the bank?

What is your goal? To produce valuable, working software? Or to
collect story points?

Why do you use story points? To measure the worth of the team? Or to
help the team select approximately the right amount of work for the next
iteration?

- George

--
------------ --------- --------- --------- --------- --------- -
* George Dinwiddie * http://blog. gdinwiddie. com
Software Development http://www.idiacomp uting.com
Consultant and Coach http://www.agilemar yland.org
------------ --------- --------- --------- --------- --------- -

Message 11 of 17 , Apr 2, 2009

On Thu, Apr 2, 2009 at 7:31 AM, <mike.dwyer1@...> wrote:
> George
> A favor to ask. Can you lead with your response? I am living on a BB these
> days and my thumb is sore from scrolling to the bottom.
>
> Sent via BlackBerry by AT&T
>
> ________________________________
> From: George Dinwiddie
> Date: Thu, 02 Apr 2009 08:00:55 -0400
> To: <scrumdevelopment@yahoogroups.com>
> Subject: Re: [scrumdevelopment] Conservation of Size Points, AKA: Partial
> Credit for Backlogs
>
> Steve Teske wrote:
>> We are having a lively debate about Size Points...
>>
>> ...giving partial
>> credit to the failing sprint
>>
>> ...give yourself zero credit
>> in the failing sprint and carry over...
>> ...full credit from the original size points (don't reduce).
>>
>> Mathematically these two paradigms result in EXACTLY the same
>> velocity calculation.
>>
>> Here's my dilema: I think the math above does not reflect true
>> velocity. I don't have a palatable explanation of why partial credit
>> schemes will fail to delivery the correct velocity measurement. But
>> the harder isssue is the politics of counting instantaneous velocity
>> (counting only the things that are DONE) and discarding the size
>> points of partially completed work appears to reduce the overall
>> backlog size. It appears that size points are disappearing if I
>> count only the "Done" work. While I believe this promotes a better
>> understanding of TRUE velocity, the politics and the Math of what I
>> call non-conservation of size points is apparently either my
>> misunderstanding of SCRUM or it's a bridge too far for my director to
>> sell to Project Management because in non-conservation of size
>> points, it looks like size points are mysteriously disappearing.
>
> Steve, I was traveling yesterday and see you've already received a lot
> of good replies. I'd like to approach this in a slightly different
> fashion, though others have hinted in this direction.
>
> Why does your organization give so much importance to story points? Why
> do you think they're a credit to the team? Why does your Project
> Management think they're something to put in the bank?
>
> What is your goal? To produce valuable, working software? Or to
> collect story points?
>
> Why do you use story points? To measure the worth of the team? Or to
> help the team select approximately the right amount of work for the next
> iteration?
>
> - George
>
> --
> ----------------------------------------------------------
> * George Dinwiddie * http://blog.gdinwiddie.com
> Software Development http://www.idiacomputing.com
> Consultant and Coach http://www.agilemaryland.org
> ----------------------------------------------------------
>
>
• ... Sorry, Mike, but whether I top-post or bottom-post, I ll make someone unhappy. So I tend to stick with my own preference, which is to make the post
Message 12 of 17 , Apr 2, 2009
mike.dwyer1@... wrote:
> George
> A favor to ask. Can you lead with your response? I am living on a BB
> these days and my thumb is sore from scrolling to the bottom.

Sorry, Mike, but whether I top-post or bottom-post, I'll make someone
unhappy. So I tend to stick with my own preference, which is to make
the post readable from top to bottom.

You might notice that I excerpted the post to which I was replying.
There's information content in that fact, also. I was trying to
highlight the specific things to which I was responding.

Perhaps a blackberry is not the best tool for participating in a mailing
list.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
• Choose b. The analogy I use in this discussion of hangover is that of earnings per share. A public company that is 90% complete in closing a deal at the end of
Message 13 of 17 , Apr 2, 2009
Choose b.

The analogy I use in this discussion of hangover is that of earnings per share.

A public company that is 90% complete in closing a deal at the end of Q1, cannot claim any portion of the revenue from that deal. If they finally complete the deal in Q2, they claim the revenue then. Do they adjust their expectations up for Q2 given this understanding? No. Why? Because - at the end of Q2, they're likely to have incomplete deals as well, which will offset the positive impact of the hangover.

And so it goes. It all evens out. Just like iteration points.

And by all means, have more stories on deck to slide into the iteration if the team hits on all cylinders in the next iteration.

There's another smell here though... if you consistently have hangover, then something is amiss. Perhaps your stories are too big or poorly conceived (a common problem), or your planned velocity (commitment) is too high.

I'm currently working on a team on which hangover is rare; when it occurs, it is usually due to some exigent factor (e.g. dependency/commitment not being met by another team). If not, it usually gets done in day one of the next iteration.

That said, I've seen teams with massive hangover.

If you can't figure out the issue, I recommend bringing in an outside expert to help facilitate/diagnose. In particular, find someone who has actually participated in many teams in many environments and who has seen many problems. That is - don't find a theoretical agilist with PowerPoint at the ready... use a practiced one with post-its, markers, flipcharts, stories, analogies and enthusiasm.

Software Development Catalyst

--- In scrumdevelopment@yahoogroups.com, "steveteske" <steveteske@...> wrote:
>
> We are having a lively debate about Size Points. I am calling the "Conservation of Size Points Debate", because the following practices of your SCRUM Masters:
>
> Either a) If you don't finish a backlog item, estimate the remaining size of the backlog and assign it to the next sprint, giving partial credit to the failing sprint (thus preserving the overall size points)
>
> or b) If you don't finish a backlog item, give yourself zero credit in the failing sprint and carry over the size points (without reduction) to the next sprint. When you actual finish the backlog, you get count credit for in the sprint in which it is finished...but it's full credit from the original size points (don't reduce).
>
> Mathematically these two paradigms result in EXACTLY the same velocity calculation.
>
> Here's my dilema: I think the math above does not reflect true velocity. I don't have a palatable explanation of why partial credit schemes will fail to delivery the correct velocity measurement. But the harder isssue is the politics of counting instantaneous velocity (counting only the things that are DONE) and discarding the size points of partially completed work appears to reduce the overall backlog size. It appears that size points are disappearing if I count only the "Done" work. While I believe this promotes a better understanding of TRUE velocity, the politics and the Math of what I call non-conservation of size points is apparently either my misunderstanding of SCRUM or it's a bridge too far for my director to sell to Project Management because in non-conservation of size points, it looks like size points are mysteriously disappearing.
>
> I don't have a problem with disappearing size points because according to my math, if I have TRUE velocity and the total size points to the next release, I've got what I need.
>
> I am not sure how to deal with conservation vs. non-conservation of size points.
>
> Help would be appreciated.
>
> Steve Teske
> Thales Communications Inc., Clarksburg, MD
>
• ... I consistently have hangover, but I drink a lot... ;-) The goals of the planning process are: 1) to come to a shared understanding of what needs to be done
Message 14 of 17 , Apr 2, 2009
On Thu, Apr 2, 2009 at 9:27 PM, awible <apwible@...> wrote:
> Choose b.
>
> The analogy I use in this discussion of hangover is that of earnings per
> share.
>
> A public company that is 90% complete in closing a deal at the end of Q1,
> cannot claim any portion of the revenue from that deal. If they finally
> complete the deal in Q2, they claim the revenue then. Do they adjust their
> expectations up for Q2 given this understanding? No. Why? Because - at the
> end of Q2, they're likely to have incomplete deals as well, which will
> offset the positive impact of the hangover.
>
> And so it goes. It all evens out. Just like iteration points.
>
> And by all means, have more stories on deck to slide into the iteration if
> the team hits on all cylinders in the next iteration.
>
> There's another smell here though... if you consistently have hangover, then
> something is amiss. Perhaps your stories are too big or poorly conceived (a
> common problem), or your planned velocity (commitment) is too high.
>

I consistently have hangover, but I drink a lot... ;-)

The goals of the planning process are: 1) to come to a shared
understanding of what needs to be done and what will be done in the
current iteration. 2) to give the business a way to understand how
much can be done in a given period and/or approximately when a certain
set of features will be complete. These goals are not well served by a
process that allows work to bleed across sprint boundaries.

The point behind allowing partial stories to "disappear" rather than
"hangover" is that apparent velocity decreases leading to more
conservative commitments that are more likely to be met. Thus the
process should adjust to the actual capabilities of the team.

> I'm currently working on a team on which hangover is rare; when it occurs,
> it is usually due to some exigent factor (e.g. dependency/commitment not
> being met by another team). If not, it usually gets done in day one of the
> next iteration.
>

And, therefore you don't have a problem. It is also unlikely that you
would have asked the question. The advice that I am giving is designed
to help people who frequently (Or at least occasionally) face this
problem. Slowing down is likely to help in the short term.

> That said, I've seen teams with massive hangover.
>

Probably because of a) poor estimation, b) over commitment, and/or c)
lack of communication (i.e. poorly understood requirements.) Lowering
the velocity is likely to help with both a and b. If c isn't detected
and dealt with the process will break down and the team will grind to
a halt, but estimation isn't the problem and no estimation strategy
will help.

> If you can't figure out the issue, I recommend bringing in an outside expert
> to help facilitate/diagnose. In particular, find someone who has actually
> participated in many teams in many environments and who has seen many
> problems. That is - don't find a theoretical agilist with PowerPoint at the
> ready... use a practiced one with post-its, markers, flipcharts, stories,
> analogies and enthusiasm.
>

Good idea.
Your message has been successfully submitted and would be delivered to recipients shortly.