Browse Groups

• Hey everyone, At my organisation, a discussion has recently broken out that I would like some opinion/clarification on. At the end of a sprint, it is well
Message 1 of 19 , Aug 9, 2010
View Source
Hey everyone,

At my organisation, a discussion has recently broken out that I would like some opinion/clarification on. At the end of a sprint, it is well understood that you can only claim points for completed stories, but from my understanding the following two things are not correct:

1) If the team has a 5 point story and it is felt that they spent closer to 8 points of effort on it, we can change the claimed number of points to 8 once the story is complete (again provided it is in the same sprint).
2) If a team completes a bonus activity or story in a sprint, (for example in refactoring some work we manage to allow our self to extend the functionality of the product easily and cheaply as we had asked for in a future story) we can claim those bonus points for this sprint. (Apologies for the example here, it is a bit naive but only meant to be illustrative).

I was led to believe in my agile training and readings that both those points were incorrect,. Am I correct or is it down to interpretation?

Thanks

Paul

• ... You could, but tracking velocity incorporates the uncertainty of estimation, so there isn t much point. Just learn from it and attempt better estimates for
Message 1 of 19 , Aug 9, 2010
View Source
On Mon, Aug 9, 2010 at 2:15 PM, Paul Battisson wrote:

1) If the team has a 5 point story and it is felt that they spent closer to 8 points of effort on it, we can change the claimed number of points to 8 once the story is complete (again provided it is in the same sprint).

You could, but tracking velocity incorporates the uncertainty of estimation, so there isn't much point. Just learn from it and attempt better estimates for subsequent sprints.

2) If a team completes a bonus activity or story in a sprint, (for example in refactoring some work we manage to allow our self to extend the functionality of the product easily and cheaply as we had asked for in a future story) we can claim those bonus points for this sprint. (Apologies for the example here, it is a bit naive but only meant to be illustrative).

No I don't think so. I guess the "bonus" would come in being able to readjust backlog items with a lower estimate, and thus get more done in future sprints.

Try not to think of velocity as a score, as in more is better. It is simply a tool to help plan the next sprint. Trying to game it doesn't improve anything real.
• ... Both those things are incorrect. You are correct. I will write more later if it seems to be needed. Briefly, this kind of focus on points is evidence that
Message 1 of 19 , Aug 9, 2010
View Source
Hello, Paul. On Monday, August 9, 2010, at 8:15:59 AM, you wrote:

> I was led to believe in my agile training and readings that both those points
> were incorrect,. Am I correct or is it down to interpretation?

Both those things are incorrect. You are correct. I will write more
later if it seems to be needed.

Briefly, this kind of focus on points is evidence that the team is
being scored by how many points they accomplish. That is not a good
way to operate a team.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
(I am large, I contain multitudes.) --Walt Whitman
• The purpose if the points/velocity is just to help you learn by what you have actually done. Hopefully what you actually have done allows you to guess/
Message 1 of 19 , Aug 9, 2010
View Source
The purpose if the points/velocity is just to help you learn by what you have actually done. Hopefully what you actually have done allows you to guess/ estimate that little but better in the next sprint with the same team. Don't get hung up on comparing teams and over analysing.

Kevin

Sent from my iPhone

On 9 Aug 2010, at 13:15, Paul Battisson <paulbattisson@...> wrote:

Hey everyone,

At my organisation, a discussion has recently broken out that I would like some opinion/clarificati on on. At the end of a sprint, it is well understood that you can only claim points for completed stories, but from my understanding the following two things are not correct:

1) If the team has a 5 point story and it is felt that they spent closer to 8 points of effort on it, we can change the claimed number of points to 8 once the story is complete (again provided it is in the same sprint).
2) If a team completes a bonus activity or story in a sprint, (for example in refactoring some work we manage to allow our self to extend the functionality of the product easily and cheaply as we had asked for in a future story) we can claim those bonus points for this sprint. (Apologies for the example here, it is a bit naive but only meant to be illustrative) .

I was led to believe in my agile training and readings that both those points were incorrect,. Am I correct or is it down to interpretation?

Thanks

Paul

• Thanks guys, it is good to clarify things just for certainty. I am trying to move the focus in the team away from a score and more onto targets and goals of
Message 1 of 19 , Aug 9, 2010
View Source
Thanks guys, it is good to clarify things just for certainty. I am trying to move the focus in the team away from a "score" and more onto targets and goals of functionality. Again thanks for all your help.

From: Ron Jeffries <ronjeffries@...>
To: scrumdevelopment@yahoogroups.com
Sent: Mon, August 9, 2010 1:34:28 PM
Subject: Re: [scrumdevelopment] Discussion Point

Hello, Paul. On Monday, August 9, 2010, at 8:15:59 AM, you wrote:

> I was led to believe in my agile training and readings that both those points
> were incorrect,. Am I correct or is it down to interpretation?

Both those things are incorrect. You are correct. I will write more
later if it seems to be needed.

Briefly, this kind of focus on points is evidence that the team is
being scored by how many points they accomplish. That is not a good
way to operate a team.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
(I am large, I contain multitudes.) --Walt Whitman

• Wanting credit for extra effort and for bonus work can also be a warning flag that the team is feeling under-appreciated for the effort they re putting in, and
Message 1 of 19 , Aug 9, 2010
View Source
Wanting credit for extra effort and for bonus work can also be a warning flag
that the team is feeling under-appreciated for the effort they're putting in,
and that you have an underlying morale problem to deal with.

Dave

On Mon, Aug 9, 2010 at 5:34 AM, Ron Jeffries wrote:
Hello, Paul.  On Monday, August 9, 2010, at 8:15:59 AM, you wrote:

> I was led to believe in my agile training and readings that both those points
> were incorrect,. Am I correct or is it down to interpretation?

Both those things are incorrect. You are correct. I will write more
later if it seems to be needed.

Briefly, this kind of focus on points is evidence that the team is
being scored by how many points they accomplish. That is not a good
way to operate a team.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
(I am large, I contain multitudes.) --Walt Whitman

------------------------------------

To Post a message, send it to:   scrumdevelopment@...
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> To change settings online go to:
http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)

<*> To change settings via email:
scrumdevelopment-digest@yahoogroups.com
scrumdevelopment-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

• The best way to get extra credit for development points is to re-evaluate your point scoring method, and re-estimate your Product Backlog. Instead of using a
Message 1 of 19 , Aug 9, 2010
View Source
The best way to get extra credit for development points is to re-evaluate your point scoring method, and re-estimate your Product Backlog. Instead of using a 1-2-4-8 story points scale, use a 4-8-16-32 scale. That way your points score increases hugely, and your managers should be very pleased.

Regards,
Roy Morien

To: scrumdevelopment@yahoogroups.com
From: davewsmith@...
Date: Mon, 9 Aug 2010 11:03:59 -0700
Subject: Re: [scrumdevelopment] Discussion Point

Wanting credit for extra effort and for bonus work can also be a warning flag
that the team is feeling under-appreciated for the effort they're putting in,
and that you have an underlying morale problem to deal with.

Dave

On Mon, Aug 9, 2010 at 5:34 AM, Ron Jeffries wrote:
Hello, Paul.  On Monday, August 9, 2010, at 8:15:59 AM, you wrote:

> I was led to believe in my agile training and readings that both those points
> were incorrect,. Am I correct or is it down to interpretation?

Both those things are incorrect. You are correct. I will write more
later if it seems to be needed.

Briefly, this kind of focus on points is evidence that the team is
being scored by how many points they accomplish. That is not a good
way to operate a team.

Ron Jeffries
www.XProgramming. com
www.xprogramming. com/blog
(I am large, I contain multitudes.) --Walt Whitman

------------ --------- --------- ------

To Post a message, send it to:   scrumdevelopment@ eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment- unsubscribe@ eGroups.comYahoo ! Groups Links

<*> To visit your group on the web, go to:
http://groups. yahoo.com/ group/scrumdevel opment/

<*> To change settings online go to:
http://groups. yahoo.com/ group/scrumdevel opment/join
(Yahoo! ID required)

<*> To change settings via email:
scrumdevelopment- digest@yahoogrou ps.com
scrumdevelopment- fullfeatured@ yahoogroups. com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment- unsubscribe@ yahoogroups. com

<*> Your use of Yahoo! Groups is subject to:
http://docs. yahoo.com/ info/terms/

• ... Brilliant! Ron Jeffries www.XProgramming.com www.xprogramming.com/blog A lot of preconceptions can be dismissed when you actually try something out. --
Message 1 of 19 , Aug 9, 2010
View Source
Hello, Roy. On Monday, August 9, 2010, at 10:59:15 PM, you wrote:

> The best way to get extra credit for development points is to
> re-evaluate your point scoring method, and re-estimate your
> Product Backlog. Instead of using a 1-2-4-8 story points scale,
> use a 4-8-16-32 scale. That way your points score increases

Brilliant!

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
A lot of preconceptions can be dismissed when you actually
try something out. -- Bruce Eckel
• There seems to be no issue understanding that it is a relative system and that the number doesn t matter, but somewhere along the line a points to hours
Message 1 of 19 , Aug 10, 2010
View Source
There seems to be no issue understanding that it is a relative system and that the number doesn't matter, but somewhere along the line a points to hours conversion seems to have slipped in. I am trying to squash that fallacy but such questions as the points I raised are asked - they are telling me "but that the way we were trained".

From: Ron Jeffries <ronjeffries@...>
To: scrumdevelopment@yahoogroups.com
Sent: Tue, August 10, 2010 4:14:48 AM
Subject: Re: [scrumdevelopment] Discussion Point

Hello, Roy.  On Monday, August 9, 2010, at 10:59:15 PM, you wrote:

> The best way to get extra credit for development points is to
> re-evaluate your point scoring method, and re-estimate your
> Product Backlog. Instead of using a 1-2-4-8 story points scale,
> use a 4-8-16-32 scale. That way your points score increases

Brilliant!

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
A lot of preconceptions can be dismissed when you actually
try something out. -- Bruce Eckel

------------------------------------

To Post a message, send it to:  scrumdevelopment@...
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

<*> To visit your group on the web, go to:

<*> To change settings online go to:

(Yahoo! ID required)

<*> To change settings via email:
scrumdevelopment-digest@yahoogroups.com
scrumdevelopment-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:

• My grandfather was trained as a blacksmith ... he had a great career putting iron tyres on the wheels of carriages. Yes, that was the way he was trained. But
Message 1 of 19 , Aug 10, 2010
View Source
My grandfather was trained as a blacksmith ... he had a great career putting iron 'tyres' on the wheels of carriages.

Yes, that was the way he was trained.

But when rubber tyres became common on cars, he stopped trying to put iron tyres on wheels, even though that was the way he was trained.

Maybe there is a moral to this little story.

Regards,
Roy Morien

To: scrumdevelopment@yahoogroups.com
From: paulbattisson@...
Date: Tue, 10 Aug 2010 01:32:43 -0700
Subject: Re: [scrumdevelopment] Discussion Point

There seems to be no issue understanding that it is a relative system and that the number doesn't matter, but somewhere along the line a points to hours conversion seems to have slipped in. I am trying to squash that fallacy but such questions as the points I raised are asked - they are telling me "but that the way we were trained".

From: Ron Jeffries <ronjeffries@ acm.org>
To: scrumdevelopment@ yahoogroups. com
Sent: Tue, August 10, 2010 4:14:48 AM
Subject: Re: [scrumdevelopment] Discussion Point

Hello, Roy.  On Monday, August 9, 2010, at 10:59:15 PM, you wrote:

> The best way to get extra credit for development points is to
> re-evaluate your point scoring method, and re-estimate your
> Product Backlog. Instead of using a 1-2-4-8 story points scale,
> use a 4-8-16-32 scale. That way your points score increases

Brilliant!

Ron Jeffries
www.XProgramming. com
www.xprogramming. com/blog
A lot of preconceptions can be dismissed when you actually
try something out. -- Bruce Eckel

------------ --------- --------- ------

To Post a message, send it to:  scrumdevelopment@ eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment- unsubscribe@ eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:

<*> To change settings online go to:

(Yahoo! ID required)

<*> To change settings via email:
scrumdevelopment- digest@yahoogrou ps.com
scrumdevelopment- fullfeatured@ yahoogroups. com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment- unsubscribe@ yahoogroups. com

<*> Your use of Yahoo! Groups is subject to:

• (responding to Paul) I ll try to add to the good answers you already had. ... That doesn t help, because you are comparing against pre-existing estimations
Message 1 of 19 , Aug 10, 2010
View Source
(responding to Paul)

> 1) If the team has a 5 point story and it is felt that they spent
> closer to 8 points of effort on it, we can change the claimed
> number of points to 8 once the story is complete

That doesn't help, because you are comparing against pre-existing
estimations that are equally likely to be equally accurate (or not).
If you have reason to believe things in the backlog have been "put
in the wrong bag size" then a re-estimate may be worth doing.
Normally it isn't worth doing (hint).

planning when, as a team, you decide how much to commit to. The
points give an idea of where you will be in a few iterations' time,
and if you try to use them for anything else you risk breaking
this mechanism.

> 2) If a team completes a bonus activity or story in a sprint,
> (for example in refactoring some work we manage to allow our
> self to extend the functionality of the product easily and
> cheaply as we had asked for in a future story) we can
> claim those bonus points for this sprint.

splitting stories and sizing them... but again rather than
adjusting I would take the lessons learned to the retrospective.
Again you might find there's a generic situation with many
stories in the backlog, but if you adjust the backlog your
existing velocity is thrown in doubt. How important is it that
you need to predict well over the next few iterations? It may
take that long to get back to a velocity that is reasonably
reliable.

Hope this helps.
Paul Oldfield
Capgemini
• Wow! This seems massively misguided to me. The Team s velocity is the Team s velocity. It s not something that incentives should be based on and they should
Message 1 of 19 , Aug 10, 2010
View Source
Wow! This seems massively misguided to me.

The Team's velocity is the Team's velocity. It's not something that
incentives should be based on and they should never be scrambling to pick
up "points" after the fact.

That being said, the velocity is simply a planning tool. So you want it to
be as accurate as possible. Do you retroactively bump up the story points
for a really bad estimate? Maybe, if doing so is going to lead to more
accurate planning.

Dave Barrett
Project Manager
Lawyers' Professional Indemnity Company (LAWPRO®)
3101 - 250 Yonge Street
Toronto, Ontario M5B 2L7
Tel: 416-598-5800
Fax: 416-599-8341

This e-mail may be privileged and/or confidential, and the sender does not
waive any related rights and obligations. Any distribution, use or copying
of this e-mail or the information it contains by other than an intended
delete it and advise me (by return e-mail or otherwise) immediately.

Ce courrier électronique est confidentiel et protégé. L'expéditeur ne
renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion,
utilisation ou copie de ce message ou des renseignements qu'il contient par
une personne autre que le (les) destinataire(s) désigné(s) est interdite.
Si vous recevez ce courrier électronique par erreur, veuillez le supprimer
et m'en aviser immédiatement, par retour de courrier électronique ou par un
autre moyen.
• Woah! For less experienced agile teams, I suggest going to a 2-4-8-16 scale first. That 32 can be a little hard to handle. Regards, Lance
Message 1 of 19 , Aug 10, 2010
View Source
Woah!

For less experienced agile teams, I suggest going to a 2-4-8-16 scale first. That 32 can be a little hard to handle.

Regards,

Lance

--- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@...> wrote:
>
>
> The best way to get extra credit for development points is to re-evaluate your point scoring method, and re-estimate your Product Backlog. Instead of using a 1-2-4-8 story points scale, use a 4-8-16-32 scale. That way your points score increases hugely, and your managers should be very pleased.
>
>
>
> Regards,
>
> Roy Morien
>
>
>
• If you try to go back and re-estimate retrospectively (if that is not a contradiction in terms), what are you trying to achieve, and what do you achieve? To
Message 1 of 19 , Aug 10, 2010
View Source
If you try to go back and re-estimate retrospectively (if that is not a contradiction in terms), what are you trying to achieve, and what do you achieve?

To change the number of story points after the event for one User Story might change the apparent velocity of the team by a small fraction, because the contribution of the delta in story points to velocity is very very small. So it is pointless anyway.

If your intention is to measure a more 'accurate' velocity, then this is not worth doing. Velocity will converge on a reasonably valid predictive number over time (meaning, over more sprints).

If your intention is to make your points 'score' look good, then that is not very useful. Story points achieved is not some competitive value that can be used to determine the competence and efficiency of the team. If you want to do this, take my suggestion of upping your points scale to 4-8-16-32 .... this can really make you look good. But, be careful of 32! :)

Regards,
Roy Morien

To: scrumdevelopment@yahoogroups.com
From: dave.barrett@...
Date: Tue, 10 Aug 2010 09:33:18 -0400
Subject: [scrumdevelopment] Re:Discussion Point

Wow! This seems massively misguided to me.

The Team's velocity is the Team's velocity. It's not something that
incentives should be based on and they should never be scrambling to pick
up "points" after the fact.

That being said, the velocity is simply a planning tool. So you want it to
be as accurate as possible. Do you retroactively bump up the story points
for a really bad estimate? Maybe, if doing so is going to lead to more
accurate planning.

Dave Barrett
Project Manager
Lawyers' Professional Indemnity Company (LAWPRO®)
3101 - 250 Yonge Street
Toronto, Ontario M5B 2L7
Tel: 416-598-5800
Fax: 416-599-8341

This e-mail may be privileged and/or confidential, and the sender does not
waive any related rights and obligations. Any distribution, use or copying
of this e-mail or the information it contains by other than an intended
delete it and advise me (by return e-mail or otherwise) immediately.

Ce courrier électronique est confidentiel et protégé. L'expéditeur ne
renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion,
utilisation ou copie de ce message ou des renseignements qu'il contient par
une personne autre que le (les) destinataire(s) désigné(s) est interdite.
Si vous recevez ce courrier électronique par erreur, veuillez le supprimer
et m'en aviser immédiatement, par retour de courrier électronique ou par un
autre moyen.

• Dave I agree with you, the teams velocity, tends to be a teams velocity, use it for what it is, a high accuracy, low precision planning tool. Because of that I
Message 1 of 19 , Aug 11, 2010
View Source
Dave

I agree with you, the teams velocity, tends to be a teams velocity, use it for what it is, a high accuracy, low precision planning tool.

Because of that I would be careful about the phrase "as accurate as possible."  I've seen it lead to seriously inappropriate attempts at precision.

Precision is expensive and often a waste of time, energy and money.

If I ask you how warm it is outside, all I want to know is do I need a coat, or sunscreen.

"Hot", "Warm", "Cool", or "Coooolllld" is all the precision I need (or can really use).

I do not need to know if it's 73.8672199 degrees Fahrenheit out there.  Even if it really is 73.8672199 degrees out there at the time I ask the question, it will probably be a different number by the time I get out there.

Most attempts at estimation that I've seen, seem to operate under the following assumption
"If I can get a very precise set of estimation tools, then I can stop the weather from changing."

Malcolm Anderson CSP

On Tue, Aug 10, 2010 at 8:33 AM, wrote:

Wow! This seems massively misguided to me.

The Team's velocity is the Team's velocity. It's not something that
incentives should be based on and they should never be scrambling to pick
up "points" after the fact.

That being said, the velocity is simply a planning tool. So you want it to
be as accurate as possible. Do you retroactively bump up the story points
for a really bad estimate? Maybe, if doing so is going to lead to more
accurate planning.

Dave Barrett

• Thanks Lance, ... I needed my daily fix of laughter. Thanks for delivering. Yours Sincerely, Petri
Message 1 of 19 , Aug 11, 2010
View Source
Thanks Lance,

> For less experienced agile teams, I suggest going to a 2-4-8-16 scale first. That 32 can be a little hard to handle.

I needed my daily fix of laughter. Thanks for delivering.

Yours Sincerely, Petri

> --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@> wrote:
> >
> >
> > The best way to get extra credit for development points is to re-evaluate your point scoring method, and re-estimate your Product Backlog. Instead of using a 1-2-4-8 story points scale, use a 4-8-16-32 scale. That way your points score increases hugely, and your managers should be very pleased.
> >
> >
> >
> > Regards,
> >
> > Roy Morien
> >
> >
> >
>
• We have encountered similar issues throughout our Scrum implementation. The way we ve chosen to accommodate these issues is: 1) Planning I meeting - team
Message 1 of 19 , Aug 11, 2010
View Source

We have encountered similar issues throughout our Scrum implementation.  The way we’ve chosen to accommodate these issues is:

1)      Planning I meeting – team and PO agree on PBIs (work commitment) and Goal for Sprint.  Planning II meeting – team breaks PBI work into individual tasks (SBIs) with hours estimates for each.  The team uses Planning Poker to estimate story point size of PBIs.  If after Planning Meeting II the team discovers the amount of real work to implement a story outweighs the allotted story points then we call the PO into the meeting to discuss options.  Options are – 1) do nothing, leave the story points/work as estimated.  2) adjust story points up/down to be more in-line with past PBI sizing.  3) alter (usually reduce) the scope of the PBI to be more commensurate with the estimated size of the PBI.

2)      No concept of bonus points in Scrum.  If the team encounters work during the course of the Sprint we’ll discuss with the PO.  At a minimum it is recorded as a PBI for future attention.  In some instances it is a defect and can be logged as a production “bug” for future attention.  If it is refactoring work the team decides whether or not to accept the additional work with the committed items already in place for the Sprint.  …or create a technical debt PBI for future attention.

Regarding item 1 above – in our two and a half year journey with Scrum we’ve change story points two times.   Usually this is because the estimating work was done several Sprints back and/or new awareness of issues during the actual work to breakdown the PBI into discrete tasks uncovers unexpected work.

Our approach.  …your mileage may vary.

Chris

From: Paul Battisson [mailto:paulbattisson@...]
Sent: Monday, August 09, 2010 8:16 AM
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] Discussion Point

Hey everyone,

At my organisation, a discussion has recently broken out that I would like some opinion/clarification on. At the end of a sprint, it is well understood that you can only claim points for completed stories, but from my understanding the following two things are not correct:

1) If the team has a 5 point story and it is felt that they spent closer to 8 points of effort on it, we can change the claimed number of points to 8 once the story is complete (again provided it is in the same sprint).

2) If a team completes a bonus activity or story in a sprint, (for example in refactoring some work we manage to allow our self to extend the functionality of the product easily and cheaply as we had asked for in a future story) we can claim those bonus points for this sprint. (Apologies for the example here, it is a bit naive but only meant to be illustrative).

I was led to believe in my agile training and readings that both those points were incorrect,. Am I correct or is it down to interpretation?

Thanks

Paul

• Hi all, It seems to me that the most important thing is being able to use the the storypoints and velocity as planning/prediction tools. Thus scoring extra
Message 1 of 19 , Aug 11, 2010
View Source
Hi all,

It seems to me that the most important thing is being able to use the the storypoints and velocity as planning/prediction tools. Thus "scoring" extra story points in a sprint is by no means a desirable thing. It is (almost) as bad, as not reaching your sprint commitment, as it screws up the predictability just as much.

Thus, I think that using "score" as a term for the amassed storypoints in a sprint is unfitting and counterproductive for what we are trying to acheive.

If you absolutely crave some kind of score, maybe you could try to calculate the "off-target percentage" - meaning how much you miss your commitment by at each sprint. Given a sprint commitment of 100 Sp, both 90 and 110 sp would score 10%. A score of 0% is, of course, the bullseye we aim for.

We'll hit the bullseye more and more frequently as we improve our process and planning skills... unless some annoying manager starts to fiddle with the darts or begins to shake the dart board with the darts in mid-flight.

Regards,
Morten

--- In scrumdevelopment@yahoogroups.com, Paul Battisson <paulbattisson@...> wrote:
>
> Hey everyone,
>
> At my organisation, a discussion has recently broken out that I would like some
> opinion/clarification on. At the end of a sprint, it is well understood that you
> can only claim points for completed stories, but from my understanding the
> following two things are not correct:
>
> 1) If the team has a 5 point story and it is felt that they spent closer to 8
> points of effort on it, we can change the claimed number of points to 8 once the
> story is complete (again provided it is in the same sprint).
> 2) If a team completes a bonus activity or story in a sprint, (for example in
> refactoring some work we manage to allow our self to extend the functionality of
> the product easily and cheaply as we had asked for in a future story) we can
> claim those bonus points for this sprint. (Apologies for the example here, it is
> a bit naive but only meant to be illustrative).
>
> I was led to believe in my agile training and readings that both those points
> were incorrect,. Am I correct or is it down to interpretation?
>
> Thanks
>
> Paul
>
• Hi Paul, It s natural when your first start out with agile to get excited about whether something is 5pts or 8pts. To claim extra story points or not. At the
Message 1 of 19 , Aug 11, 2010
View Source
Hi Paul,

It's natural when your first start out with agile to get excited about whether something is 5pts or 8pts. To claim extra story points or not.

At the end of the day it doesn't really matter.

For every story point you claim 5pts when it was really worth 8pts, there will be an 8pt story that was really worth 5pts. So don't get too excited about that. It all comes out in the wash.

What do they really care about?

Is it be whether you got 5 or 8 pts for a story?

Or whether you shipped working software they could potentially put into production with the next release.

Good luck - JR

http://agilewarrior.wordpress.com
The Agile Samurai - http://bit.ly/9wlCdz

--- In scrumdevelopment@yahoogroups.com, Paul Battisson <paulbattisson@...> wrote:
>
> Hey everyone,
>
> At my organisation, a discussion has recently broken out that I would like some
> opinion/clarification on. At the end of a sprint, it is well understood that you
> can only claim points for completed stories, but from my understanding the
> following two things are not correct:
>
> 1) If the team has a 5 point story and it is felt that they spent closer to 8
> points of effort on it, we can change the claimed number of points to 8 once the
> story is complete (again provided it is in the same sprint).
> 2) If a team completes a bonus activity or story in a sprint, (for example in
> refactoring some work we manage to allow our self to extend the functionality of
> the product easily and cheaply as we had asked for in a future story) we can
> claim those bonus points for this sprint. (Apologies for the example here, it is
> a bit naive but only meant to be illustrative).
>
> I was led to believe in my agile training and readings that both those points
> were incorrect,. Am I correct or is it down to interpretation?
>
> Thanks
>
> Paul
>
Your message has been successfully submitted and would be delivered to recipients shortly.
• Changes have not been saved
Press OK to abandon changes or Cancel to continue editing
• Your browser is not supported
Kindly note that Groups does not support 7.0 or earlier versions of Internet Explorer. We recommend upgrading to the latest Internet Explorer, Google Chrome, or Firefox. If you are using IE 9 or later, make sure you turn off Compatibility View.