## Re: [scrumdevelopment] Velocity Question

Expand Messages
• In addition I use a trailing average over three sprints to smooth out normally variance. Remember velocity has only two uses: - Give a rough guide as to how
Message 1 of 29 , May 8, 2012
• 0 Attachment
In addition I use a trailing average over three sprints to smooth out normally variance.

Remember velocity has only two uses:
- Give a rough guide as to how much of the backlog the team will complete
- Aid the team in planning for the next sprint

It isn't a Management reporting metric.

Cheers
Mark

On Tue, May 8, 2012 at 9:42 AM, Paul Hudson wrote:

On 23 April 2012 04:31, Rama Bharti wrote:
How do you explain this difference in velocity to management?

You don't.

Seriously, that two sprints differed in acheived velocity isn't something that should need justification to management.

Or if you really need to, the explanation of what happened that you gave in your email should be enough. If it's not enough, you have bigger issues that the velocity figures.

• Hi Rama How do you know that Sprint 2 has 50 points? You shouldn t be planning Sprint 2 until Sprint 1 has finished! You take the velocity achieved in Sprint
Message 2 of 29 , May 8, 2012
• 0 Attachment
Hi Rama

How do you know that Sprint 2 has 50 points? You shouldn't be planning Sprint 2 until Sprint 1 has finished! You take the velocity achieved in Sprint 1 as your starting point in planning Sprint 2 - "Yesterday's Weather".

--- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@...> wrote:
>
> Hi,
>
> I have a question on velocity.
>
> For instance, you have sprint 1 and sprint 2.
>
> Sprint 1 has 5 stories which in total is 50 story points. Each story
> is of size 10 story point.
> Sprint 2 has 5 stories which in total is 50 story points. Each story
> is of size 10 story point.
>
> Now sprint 1 ends with 3 stories completed and 2 story partially
> completed( 80 %done). What will be velocity of Sprint 1? I assume it
> will be 30.
>
> Now pending 2 stories are moved to sprint 2. and at the end of sprint
> 2 , all seven stories are finished( 2 which were moved from Sprint1
> and 5 Sprint2 stories). So velocity of sprint 2 is 70.
>
> How do you explain this difference in velocity to management?
>
>
> Thanks.
>
• Hi. Your first two paragraphs seem to suggest that you ve completed 5 stories in each of the first two sprints, but your third and fourth paragraph suggest
Message 3 of 29 , May 8, 2012
• 0 Attachment
Hi.

Your first two paragraphs seem to suggest that you've completed 5 stories in each of the first two sprints, but your third and fourth paragraph suggest that you have completed 3 in the first and 7 in the second. Can you explain that?

Your third paragraph talks about "partially completed" stories, and suggests that you can say that stories are "80% done". Can you explain what that means?

Your third paragraph talks about two stories that have been started but not finished at the end of the first sprint. Rather than explain the facts you describe to management, can you think of any different ways of working that might result in a better (even if not perfect) end to the first sprint, without increasing the sprint length?

Regards,

Lance

--- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@...> wrote:
>
> Hi,
>
> I have a question on velocity.
>
> For instance, you have sprint 1 and sprint 2.
>
> Sprint 1 has 5 stories which in total is 50 story points. Each story
> is of size 10 story point.
> Sprint 2 has 5 stories which in total is 50 story points. Each story
> is of size 10 story point.
>
> Now sprint 1 ends with 3 stories completed and 2 story partially
> completed( 80 %done). What will be velocity of Sprint 1? I assume it
> will be 30.
>
> Now pending 2 stories are moved to sprint 2. and at the end of sprint
> 2 , all seven stories are finished( 2 which were moved from Sprint1
> and 5 Sprint2 stories). So velocity of sprint 2 is 70.
>
> How do you explain this difference in velocity to management?
>
>
> Thanks.
>
• I am in agreement with previous responses to this question. However at the beginning of Sprint 2 you should re-estimate the story points for the two partially
Message 4 of 29 , May 8, 2012
• 0 Attachment
I am in agreement with previous responses to this question.
However at the beginning of Sprint 2 you should re-estimate the story points for the two partially finished stories carried over from Sprint 1.

Gopinath

--- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@...> wrote:
>
> Hi,
>
> I have a question on velocity.
>
> For instance, you have sprint 1 and sprint 2.
>
> Sprint 1 has 5 stories which in total is 50 story points. Each story
> is of size 10 story point.
> Sprint 2 has 5 stories which in total is 50 story points. Each story
> is of size 10 story point.
>
> Now sprint 1 ends with 3 stories completed and 2 story partially
> completed( 80 %done). What will be velocity of Sprint 1? I assume it
> will be 30.
>
> Now pending 2 stories are moved to sprint 2. and at the end of sprint
> 2 , all seven stories are finished( 2 which were moved from Sprint1
> and 5 Sprint2 stories). So velocity of sprint 2 is 70.
>
> How do you explain this difference in velocity to management?
>
>
> Thanks.
>
• No, that is not correct. The velocity for Sprint 1 will not include the unfinished stories. Thus, the full size of the stories will be part of the velocity
Message 5 of 29 , May 8, 2012
• 0 Attachment
No, that is not correct. The velocity for Sprint 1 will not include the unfinished stories. Thus, the full size of the stories will be part of the velocity calculation for Sprint 2. If you re-estimate the stories, the velocity will not reflect their original size.

Again, this is the reason many recommend using a rolling average when calculating velocity. A 5 point story that's completed during the first day of the 2nd Sprint will contribute zero points towards the velocity of the first Sprint, and 5 points towards the velocity of the 2nd Sprint, even though there was only a small amount of work remaining.

Mark

--- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@...> wrote:
>
> I am in agreement with previous responses to this question.
> However at the beginning of Sprint 2 you should re-estimate the story points for the two partially finished stories carried over from Sprint 1.
>
> Gopinath
>
>
> --- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@> wrote:
> >
> > Hi,
> >
> > I have a question on velocity.
> >
> > For instance, you have sprint 1 and sprint 2.
> >
> > Sprint 1 has 5 stories which in total is 50 story points. Each story
> > is of size 10 story point.
> > Sprint 2 has 5 stories which in total is 50 story points. Each story
> > is of size 10 story point.
> >
> > Now sprint 1 ends with 3 stories completed and 2 story partially
> > completed( 80 %done). What will be velocity of Sprint 1? I assume it
> > will be 30.
> >
> > Now pending 2 stories are moved to sprint 2. and at the end of sprint
> > 2 , all seven stories are finished( 2 which were moved from Sprint1
> > and 5 Sprint2 stories). So velocity of sprint 2 is 70.
> >
> > How do you explain this difference in velocity to management?
> >
> >
> > Thanks.
> >
>
• I like ranges. Working with ranges rather than absolute numbers or medians is so much nicer. Try ranges, they work. -d
Message 6 of 29 , May 8, 2012
• 0 Attachment
I like ranges. Working with ranges rather than absolute numbers or medians is so much nicer. Try ranges, they work.

-d

• The rolling average may be a good idea, because there will always be variation in velocity from sprint to sprint and it can help with longer term planning.
Message 7 of 29 , May 8, 2012
• 0 Attachment
The rolling average may be a good idea, because there will always be variation in velocity from sprint to sprint and it can help with longer term planning.

However, using it to smooth the effect of stories-not-completed-in-a-single-sprint allows the team to avoid the very thing that time-boxed sprints are meant to bring out in Scrum. The time-boxed-sprint sets up a conflict that is central to Scrum's inspect and adapt activities. There are alternatives to time-boxing that avoid this conflict, of course.

Forget about how much the estimates are, what management thinks, etc. The time-boxed sprint has told this team at least one important thing (in my view). Can the team understand what it's telling them? Can the team come up with a way to do better. They should not do this by trying to explain away the data with mathematical manipulations. They should do this by changing something that at least offers the potential of genuine improvement.

Or they could *not* change anything. They can choose. Or not. It's totally up to them...

Regards,

Lance

--- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
>
>
> No, that is not correct. The velocity for Sprint 1 will not include the unfinished stories. Thus, the full size of the stories will be part of the velocity calculation for Sprint 2. If you re-estimate the stories, the velocity will not reflect their original size.
>
> Again, this is the reason many recommend using a rolling average when calculating velocity. A 5 point story that's completed during the first day of the 2nd Sprint will contribute zero points towards the velocity of the first Sprint, and 5 points towards the velocity of the 2nd Sprint, even though there was only a small amount of work remaining.
>
> Mark
>
>
> --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@> wrote:
> >
> > I am in agreement with previous responses to this question.
> > However at the beginning of Sprint 2 you should re-estimate the story points for the two partially finished stories carried over from Sprint 1.
> >
> > Gopinath
> >
> >
> > --- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@> wrote:
> > >
> > > Hi,
> > >
> > > I have a question on velocity.
> > >
> > > For instance, you have sprint 1 and sprint 2.
> > >
> > > Sprint 1 has 5 stories which in total is 50 story points. Each story
> > > is of size 10 story point.
> > > Sprint 2 has 5 stories which in total is 50 story points. Each story
> > > is of size 10 story point.
> > >
> > > Now sprint 1 ends with 3 stories completed and 2 story partially
> > > completed( 80 %done). What will be velocity of Sprint 1? I assume it
> > > will be 30.
> > >
> > > Now pending 2 stories are moved to sprint 2. and at the end of sprint
> > > 2 , all seven stories are finished( 2 which were moved from Sprint1
> > > and 5 Sprint2 stories). So velocity of sprint 2 is 70.
> > >
> > > How do you explain this difference in velocity to management?
> > >
> > >
> > > Thanks.
> > >
> >
>
• +1 to Mark W s answer below.   ... Charles Bradley http://www.ScrumCrazy.com ... +1 to Mark W s answer below. ------- Charles Bradley
Message 8 of 29 , May 8, 2012
• 0 Attachment
+1 to Mark W's answer below.

-------
http://www.ScrumCrazy.com

From: woynam <woyna@...>
To: scrumdevelopment@yahoogroups.com
Sent: Tuesday, May 8, 2012 1:06 PM
Subject: [scrumdevelopment] Re: Velocity Question

No, that is not correct. The velocity for Sprint 1 will not include the unfinished stories. Thus, the full size of the stories will be part of the velocity calculation for Sprint 2. If you re-estimate the stories, the velocity will not reflect their original size.

Again, this is the reason many recommend using a rolling average when calculating velocity. A 5 point story that's completed during the first day of the 2nd Sprint will contribute zero points towards the velocity of the first Sprint, and 5 points towards the velocity of the 2nd Sprint, even though there was only a small amount of work remaining.

Mark

--- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@...> wrote:
>
> I am in agreement with previous responses to this question.
> However at the beginning of  Sprint 2 you should re-estimate the story points for the two partially finished stories carried over from Sprint 1.
>
> Gopinath
>
>
> --- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@> wrote:
> >
> > Hi,
> >
> > I have a question on velocity.
> >
> > For instance, you have sprint 1 and sprint 2.
> >
> > Sprint 1 has 5 stories which in total is 50 story points. Each story
> > is of size 10 story point.
> > Sprint 2 has 5 stories which in total is 50 story points. Each story
> > is of size 10 story point.
> >
> > Now sprint 1 ends with 3 stories completed and 2 story partially
> > completed( 80 %done). What will be velocity of Sprint 1? I assume it
> > will be 30.
> >
> > Now pending 2 stories are moved to sprint 2. and at the end of sprint
> > 2 , all seven stories are finished( 2 which were moved from Sprint1
> > and 5 Sprint2 stories). So velocity of sprint 2 is  70.
> >
> > How do you explain this difference in velocity to management?
> >
> >
> > Thanks.
> >
>

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

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/

• Rama, The only thing I can add to most of the responses already given is that you can tell your mgmt that your velocity reflects the truth.  The team s
Message 9 of 29 , May 8, 2012
• 0 Attachment
Rama,

The only thing I can add to most of the responses already given is that you can tell your mgmt that your velocity reflects the truth.  The team's ability to complete items will ebb and flow, generally being influenced by such factors as:
• individual impediments
• team impediments
• organizational impediments
• availability of team members (vacations, matrixed/shared team members, training, etc)
• unknown risks/complexity of items
• development practices
• the team's ability and experience with User Stories, Scrum, Story Points, and Velocity
Velocity is a (generally) self correcting planning tool to reduce the cone of uncertainty in the forecast of delivery dates.  It takes time to reduce the cone of uncertainty.

You mention Sprint 1.  If it was truly this team's Sprint 1, then I would also explain to management that velocity can be very volatile during the first 3-10 sprints, and that incremental improvements will be made to help smooth it out significantly over time.  But again, it will never be completely consistent, because Scrum team members are not clairvoyants.

Sounds like your management could use some Scrum training or coaching.

-------
http://www.ScrumCrazy.com

From: Rama Bharti <ramabharti@...>
To: scrumdevelopment@yahoogroups.com
Sent: Sunday, April 22, 2012 9:31 PM
Subject: [scrumdevelopment] Velocity Question

Hi,

I have a question on velocity.

For instance, you have sprint 1 and sprint 2.

Sprint 1 has 5 stories which in total is 50 story points. Each story
is of size 10 story point.
Sprint 2 has 5 stories which in total is 50 story points. Each story
is of size 10 story point.

Now sprint 1 ends with 3 stories completed and 2 story partially
completed( 80 %done). What will be velocity of Sprint 1? I assume it
will be 30.

Now pending 2 stories are moved to sprint 2. and at the end of sprint
2 , all seven stories are finished( 2 which were moved from Sprint1
and 5 Sprint2 stories). So velocity of sprint 2 is  70.

How do you explain this difference in velocity to management?

Thanks.

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

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/

• Thanks for your reply Charles. It clears my doubt. Regards, Rama On Tue, May 8, 2012 at 6:19 PM, Charles Bradley - Scrum Coach CSP CSM PSM I
Message 10 of 29 , May 8, 2012
• 0 Attachment

Regards,
Rama

On Tue, May 8, 2012 at 6:19 PM, Charles Bradley - Scrum Coach CSP CSM PSM I wrote:

Rama,

The only thing I can add to most of the responses already given is that you can tell your mgmt that your velocity reflects the truth.  The team's ability to complete items will ebb and flow, generally being influenced by such factors as:
• individual impediments
• team impediments
• organizational impediments
• availability of team members (vacations, matrixed/shared team members, training, etc)
• unknown risks/complexity of items
• development practices
• the team's ability and experience with User Stories, Scrum, Story Points, and Velocity
Velocity is a (generally) self correcting planning tool to reduce the cone of uncertainty in the forecast of delivery dates.  It takes time to reduce the cone of uncertainty.

You mention Sprint 1.  If it was truly this team's Sprint 1, then I would also explain to management that velocity can be very volatile during the first 3-10 sprints, and that incremental improvements will be made to help smooth it out significantly over time.  But again, it will never be completely consistent, because Scrum team members are not clairvoyants.

Sounds like your management could use some Scrum training or coaching.

-------
http://www.ScrumCrazy.com

From: Rama Bharti <ramabharti@...>
To: scrumdevelopment@yahoogroups.com
Sent: Sunday, April 22, 2012 9:31 PM
Subject: [scrumdevelopment] Velocity Question

Hi,

I have a question on velocity.

For instance, you have sprint 1 and sprint 2.

Sprint 1 has 5 stories which in total is 50 story points. Each story
is of size 10 story point.
Sprint 2 has 5 stories which in total is 50 story points. Each story
is of size 10 story point.

Now sprint 1 ends with 3 stories completed and 2 story partially
completed( 80 %done). What will be velocity of Sprint 1? I assume it
will be 30.

Now pending 2 stories are moved to sprint 2. and at the end of sprint
2 , all seven stories are finished( 2 which were moved from Sprint1
and 5 Sprint2 stories). So velocity of sprint 2 is  70.

How do you explain this difference in velocity to management?

Thanks.

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

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/

• Mark, I agree with you on If you re-estimate the stories, the velocity will not reflect their original size. Preserving the information about the original
Message 11 of 29 , May 8, 2012
• 0 Attachment
Mark,

I agree with you on "If you re-estimate the stories, the velocity will not reflect their original size."

Preserving the information about the original size estimate is one approach. I won't say it is wrong. It may be useful while doing relative estimation.

But I tend towards re-prioritizing and re-estimating the unfinished stories in the next Sprint as it reflects the current situation better.

This blog post by David Starr explains very clearly why we need to do so:
http://elegantcode.com/2008/09/16/what-to-do-with-left-over-stories/

Gopinath

--- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
>
>
> No, that is not correct. The velocity for Sprint 1 will not include the unfinished stories. Thus, the full size of the stories will be part of the velocity calculation for Sprint 2. If you re-estimate the stories, the velocity will not reflect their original size.
>
> Again, this is the reason many recommend using a rolling average when calculating velocity. A 5 point story that's completed during the first day of the 2nd Sprint will contribute zero points towards the velocity of the first Sprint, and 5 points towards the velocity of the 2nd Sprint, even though there was only a small amount of work remaining.
>
> Mark
>
>
> --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@> wrote:
> >
> > I am in agreement with previous responses to this question.
> > However at the beginning of Sprint 2 you should re-estimate the story points for the two partially finished stories carried over from Sprint 1.
> >
> > Gopinath
> >
> >
> > --- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@> wrote:
> > >
> > > Hi,
> > >
> > > I have a question on velocity.
> > >
> > > For instance, you have sprint 1 and sprint 2.
> > >
> > > Sprint 1 has 5 stories which in total is 50 story points. Each story
> > > is of size 10 story point.
> > > Sprint 2 has 5 stories which in total is 50 story points. Each story
> > > is of size 10 story point.
> > >
> > > Now sprint 1 ends with 3 stories completed and 2 story partially
> > > completed( 80 %done). What will be velocity of Sprint 1? I assume it
> > > will be 30.
> > >
> > > Now pending 2 stories are moved to sprint 2. and at the end of sprint
> > > 2 , all seven stories are finished( 2 which were moved from Sprint1
> > > and 5 Sprint2 stories). So velocity of sprint 2 is 70.
> > >
> > > How do you explain this difference in velocity to management?
> > >
> > >
> > > Thanks.
> > >
> >
>
• While I think David makes some good points in his blog post, I have found in my experiences that the value obtained by re-estimating and re-prioritizing of
Message 12 of 29 , May 8, 2012
• 0 Attachment
While I think David makes some good points in his blog post, I have found in my experiences that the value obtained by re-estimating and re-prioritizing of stories is minimal across (my experiences with)multiple teams and organizations.  The value is further minimized by getting a team to darn near eliminate carryover stories altogether.  I'd rather focus on coaching a team to avoid carryovers altogether (and keep stories small) than having to coach them on some rarely valuable practice to make sure we're providing the nth degree of transparency and re-focus of the product backlog due to carryover stories.

I do leave the door open, however, that a very small percentage of teams will get a lot of value out of re-estimating and re-prioritizing the stories as David suggests.  My guess is that this would be teams that have larger stories, longer sprints (like 1 month) and have business priorities that change quite often (due to actual changing business conditions -- not business dysfunction) -- and if that was the case, I would instead encourage them to go with smaller stories and a shorter sprint duration.  :-)  Maybe there are other rare cases that I cannot think of -- any help in enlightening me here would be much appreciated.

As such, I prefer the "leave the story estimate alone once it becomes WIP(Work In Progress)" strategy.

-------
http://www.ScrumCrazy.com

From: gopinath <gopinath_ram@...>
To: scrumdevelopment@yahoogroups.com
Sent: Tuesday, May 8, 2012 11:09 PM
Subject: [scrumdevelopment] Re: Velocity Question

Mark,

I agree with you on "If you re-estimate the stories, the velocity will not reflect their original size."

Preserving the information about the original size estimate is one approach. I won't say it is wrong. It may be useful while doing relative estimation.

But I tend towards re-prioritizing and re-estimating the unfinished stories in the next Sprint as it reflects the current situation better.

This blog post by David Starr explains very clearly why we need to do so:
http://elegantcode.com/2008/09/16/what-to-do-with-left-over-stories/

Gopinath

--- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
>
>
> No, that is not correct. The velocity for Sprint 1 will not include the unfinished stories. Thus, the full size of the stories will be part of the velocity calculation for Sprint 2. If you re-estimate the stories, the velocity will not reflect their original size.
>
> Again, this is the reason many recommend using a rolling average when calculating velocity. A 5 point story that's completed during the first day of the 2nd Sprint will contribute zero points towards the velocity of the first Sprint, and 5 points towards the velocity of the 2nd Sprint, even though there was only a small amount of work remaining.
>
> Mark
>
>
> --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@> wrote:
> >
> > I am in agreement with previous responses to this question.
> > However at the beginning of  Sprint 2 you should re-estimate the story points for the two partially finished stories carried over from Sprint 1.
> >
> > Gopinath
> >
> >
> > --- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@> wrote:
> > >
> > > Hi,
> > >
> > > I have a question on velocity.
> > >
> > > For instance, you have sprint 1 and sprint 2.
> > >
> > > Sprint 1 has 5 stories which in total is 50 story points. Each story
> > > is of size 10 story point.
> > > Sprint 2 has 5 stories which in total is 50 story points. Each story
> > > is of size 10 story point.
> > >
> > > Now sprint 1 ends with 3 stories completed and 2 story partially
> > > completed( 80 %done). What will be velocity of Sprint 1? I assume it
> > > will be 30.
> > >
> > > Now pending 2 stories are moved to sprint 2. and at the end of sprint
> > > 2 , all seven stories are finished( 2 which were moved from Sprint1
> > > and 5 Sprint2 stories). So velocity of sprint 2 is  70.
> > >
> > > How do you explain this difference in velocity to management?
> > >
> > >
> > > Thanks.
> > >
> >
>

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

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/

• I completely agree, Lance. I ve been harping for years that we spend *way* too much time focusing on estimation (and velocity) related skills and issues (i.e
Message 13 of 29 , May 9, 2012
• 0 Attachment
I completely agree, Lance. I've been harping for years that we spend *way* too much time focusing on estimation (and velocity) related skills and issues (i.e metrics), and not enough time talking about skills that will actually get the stories finished sooner with better quality.

A "perfect" estimate will never deliver anything sooner. A "perfect" velocity calculation will never deliver code sooner. "Correctly" labeling a bug/feature will never deliver code sooner.

On the other hand, improved testing, integration, design, and refactoring *will* help deliver value sooner.

Mark

--- In scrumdevelopment@yahoogroups.com, "extremeprogrammer" <LanceWalton@...> wrote:
>
> The rolling average may be a good idea, because there will always be variation in velocity from sprint to sprint and it can help with longer term planning.
>
> However, using it to smooth the effect of stories-not-completed-in-a-single-sprint allows the team to avoid the very thing that time-boxed sprints are meant to bring out in Scrum. The time-boxed-sprint sets up a conflict that is central to Scrum's inspect and adapt activities. There are alternatives to time-boxing that avoid this conflict, of course.
>
> Forget about how much the estimates are, what management thinks, etc. The time-boxed sprint has told this team at least one important thing (in my view). Can the team understand what it's telling them? Can the team come up with a way to do better. They should not do this by trying to explain away the data with mathematical manipulations. They should do this by changing something that at least offers the potential of genuine improvement.
>
> Or they could *not* change anything. They can choose. Or not. It's totally up to them...
>
> Regards,
>
> Lance
>
> --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
> >
> >
> > No, that is not correct. The velocity for Sprint 1 will not include the unfinished stories. Thus, the full size of the stories will be part of the velocity calculation for Sprint 2. If you re-estimate the stories, the velocity will not reflect their original size.
> >
> > Again, this is the reason many recommend using a rolling average when calculating velocity. A 5 point story that's completed during the first day of the 2nd Sprint will contribute zero points towards the velocity of the first Sprint, and 5 points towards the velocity of the 2nd Sprint, even though there was only a small amount of work remaining.
> >
> > Mark
> >
> >
> > --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@> wrote:
> > >
> > > I am in agreement with previous responses to this question.
> > > However at the beginning of Sprint 2 you should re-estimate the story points for the two partially finished stories carried over from Sprint 1.
> > >
> > > Gopinath
> > >
> > >
> > > --- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I have a question on velocity.
> > > >
> > > > For instance, you have sprint 1 and sprint 2.
> > > >
> > > > Sprint 1 has 5 stories which in total is 50 story points. Each story
> > > > is of size 10 story point.
> > > > Sprint 2 has 5 stories which in total is 50 story points. Each story
> > > > is of size 10 story point.
> > > >
> > > > Now sprint 1 ends with 3 stories completed and 2 story partially
> > > > completed( 80 %done). What will be velocity of Sprint 1? I assume it
> > > > will be 30.
> > > >
> > > > Now pending 2 stories are moved to sprint 2. and at the end of sprint
> > > > 2 , all seven stories are finished( 2 which were moved from Sprint1
> > > > and 5 Sprint2 stories). So velocity of sprint 2 is 70.
> > > >
> > > > How do you explain this difference in velocity to management?
> > > >
> > > >
> > > > Thanks.
> > > >
> > >
> >
>
• I have no problem re-estimating stories in the backlog that haven t started. It sounds like you re trying to equate story points with duration. A story point
Message 14 of 29 , May 9, 2012
• 0 Attachment
I have no problem re-estimating stories in the backlog that haven't started.

It sounds like you're trying to equate story points with duration. A story point represents a measure of value/size, not duration. A point point story not delivered is worth nothing to the business. If it's completed on the first day of the next Sprint, then the full value of 5 points is available at the end of the 2nd Sprint when the product is delivered.

Velocity is intended to be a rough planning tool. Spending time re-estimating work in progress is a smell. The time should be spent discussing why the story was not delivered, rather than the amount of effort required to complete it.

Mark

--- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@...> wrote:
>
>
>
> Mark,
>
> I agree with you on "If you re-estimate the stories, the velocity will not reflect their original size."
>
> Preserving the information about the original size estimate is one approach. I won't say it is wrong. It may be useful while doing relative estimation.
>
> But I tend towards re-prioritizing and re-estimating the unfinished stories in the next Sprint as it reflects the current situation better.
>
> This blog post by David Starr explains very clearly why we need to do so:
> http://elegantcode.com/2008/09/16/what-to-do-with-left-over-stories/
>
> Gopinath
>
>
>
>
>
> --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
> >
> >
> > No, that is not correct. The velocity for Sprint 1 will not include the unfinished stories. Thus, the full size of the stories will be part of the velocity calculation for Sprint 2. If you re-estimate the stories, the velocity will not reflect their original size.
> >
> > Again, this is the reason many recommend using a rolling average when calculating velocity. A 5 point story that's completed during the first day of the 2nd Sprint will contribute zero points towards the velocity of the first Sprint, and 5 points towards the velocity of the 2nd Sprint, even though there was only a small amount of work remaining.
> >
> > Mark
> >
> >
> > --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@> wrote:
> > >
> > > I am in agreement with previous responses to this question.
> > > However at the beginning of Sprint 2 you should re-estimate the story points for the two partially finished stories carried over from Sprint 1.
> > >
> > > Gopinath
> > >
> > >
> > > --- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I have a question on velocity.
> > > >
> > > > For instance, you have sprint 1 and sprint 2.
> > > >
> > > > Sprint 1 has 5 stories which in total is 50 story points. Each story
> > > > is of size 10 story point.
> > > > Sprint 2 has 5 stories which in total is 50 story points. Each story
> > > > is of size 10 story point.
> > > >
> > > > Now sprint 1 ends with 3 stories completed and 2 story partially
> > > > completed( 80 %done). What will be velocity of Sprint 1? I assume it
> > > > will be 30.
> > > >
> > > > Now pending 2 stories are moved to sprint 2. and at the end of sprint
> > > > 2 , all seven stories are finished( 2 which were moved from Sprint1
> > > > and 5 Sprint2 stories). So velocity of sprint 2 is 70.
> > > >
> > > > How do you explain this difference in velocity to management?
> > > >
> > > >
> > > > Thanks.
> > > >
> > >
> >
>
• This is one of those great, ought to be obvious statements that just leapt off the screen at me today. Awesome. I need to frame this sentence, Mark.
Message 15 of 29 , May 9, 2012
• 0 Attachment
This is one of those great, ought to be obvious statements that just leapt off the screen at me today. Awesome. I need to frame this sentence, Mark.

The time should be spent discussing why the story was not delivered, rather than the amount of effort required to complete it.

--- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@...> wrote:
>
>
>
> Mark,
>
> I agree with you on "If you re-estimate the stories, the velocity will not reflect their original size."
>
> Preserving the information about the original size estimate is one approach. I won't say it is wrong. It may be useful while doing relative estimation.
>
> But I tend towards re-prioritizing and re-estimating the unfinished stories in the next Sprint as it reflects the current situation better.
>
> This blog post by David Starr explains very clearly why we need to do so:
> http://elegantcode.com/2008/09/16/what-to-do-with-left-over-stories/
>
> Gopinath
>
>
>
>
>
> --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
> >
> >
> > No, that is not correct. The velocity for Sprint 1 will not include the unfinished stories. Thus, the full size of the stories will be part of the velocity calculation for Sprint 2. If you re-estimate the stories, the velocity will not reflect their original size.
> >
> > Again, this is the reason many recommend using a rolling average when calculating velocity. A 5 point story that's completed during the first day of the 2nd Sprint will contribute zero points towards the velocity of the first Sprint, and 5 points towards the velocity of the 2nd Sprint, even though there was only a small amount of work remaining.
> >
> > Mark
> >
> >
> > --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@> wrote:
> > >
> > > I am in agreement with previous responses to this question.
> > > However at the beginning of Sprint 2 you should re-estimate the story points for the two partially finished stories carried over from Sprint 1.
> > >
> > > Gopinath
> > >
> > >
> > > --- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I have a question on velocity.
> > > >
> > > > For instance, you have sprint 1 and sprint 2.
> > > >
> > > > Sprint 1 has 5 stories which in total is 50 story points. Each story
> > > > is of size 10 story point.
> > > > Sprint 2 has 5 stories which in total is 50 story points. Each story
> > > > is of size 10 story point.
> > > >
> > > > Now sprint 1 ends with 3 stories completed and 2 story partially
> > > > completed( 80 %done). What will be velocity of Sprint 1? I assume it
> > > > will be 30.
> > > >
> > > > Now pending 2 stories are moved to sprint 2. and at the end of sprint
> > > > 2 , all seven stories are finished( 2 which were moved from Sprint1
> > > > and 5 Sprint2 stories). So velocity of sprint 2 is 70.
> > > >
> > > > How do you explain this difference in velocity to management?
> > > >
> > > >
> > > > Thanks.
> > > >
> > >
> >
>

• Mark, I am not trying to equate story points with duration. Not sure what made it sound otherwise. Sorry if I was not clear enough. All I am trying to say is -
Message 16 of 29 , May 9, 2012
• 0 Attachment
Mark,

I am not trying to equate story points with duration. Not sure what made it sound otherwise. Sorry if I was not clear enough.

All I am trying to say is - no credit to be given for a partially completed story in Sprint 1. And the work (i.e. in terms of size) which remains in that story has to be treated as a new backlog item, re-prioritized (if necessary) and re-estimated at the beginning of Sprint 2. This will give a closer indication to the size/complexity of the work to be undertaken in Sprint 2.

Not sure whether you went through the link which I had given as reference
http://elegantcode.com/2008/09/16/what-to-do-with-left-over-stories/
This fully describes what I intended to convey.

And yes as you rightly say,time should be spent discussing why the story was not delivered and how to ensure that such occurrences are minimized. This has to be done in during Sprint 1 retrospective.

Gopinath

--- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
>
>
> I have no problem re-estimating stories in the backlog that haven't started.
>
> It sounds like you're trying to equate story points with duration. A story point represents a measure of value/size, not duration. A point point story not delivered is worth nothing to the business. If it's completed on the first day of the next Sprint, then the full value of 5 points is available at the end of the 2nd Sprint when the product is delivered.
>
> Velocity is intended to be a rough planning tool. Spending time re-estimating work in progress is a smell. The time should be spent discussing why the story was not delivered, rather than the amount of effort required to complete it.
>
> Mark
>
>
> --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@> wrote:
> >
> >
> >
> > Mark,
> >
> > I agree with you on "If you re-estimate the stories, the velocity will not reflect their original size."
> >
> > Preserving the information about the original size estimate is one approach. I won't say it is wrong. It may be useful while doing relative estimation.
> >
> > But I tend towards re-prioritizing and re-estimating the unfinished stories in the next Sprint as it reflects the current situation better.
> >
> > This blog post by David Starr explains very clearly why we need to do so:
> > http://elegantcode.com/2008/09/16/what-to-do-with-left-over-stories/
> >
> > Gopinath
> >
> >
> >
> >
> >
> > --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
> > >
> > >
> > > No, that is not correct. The velocity for Sprint 1 will not include the unfinished stories. Thus, the full size of the stories will be part of the velocity calculation for Sprint 2. If you re-estimate the stories, the velocity will not reflect their original size.
> > >
> > > Again, this is the reason many recommend using a rolling average when calculating velocity. A 5 point story that's completed during the first day of the 2nd Sprint will contribute zero points towards the velocity of the first Sprint, and 5 points towards the velocity of the 2nd Sprint, even though there was only a small amount of work remaining.
> > >
> > > Mark
> > >
> > >
> > > --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@> wrote:
> > > >
> > > > I am in agreement with previous responses to this question.
> > > > However at the beginning of Sprint 2 you should re-estimate the story points for the two partially finished stories carried over from Sprint 1.
> > > >
> > > > Gopinath
> > > >
> > > >
> > > > --- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I have a question on velocity.
> > > > >
> > > > > For instance, you have sprint 1 and sprint 2.
> > > > >
> > > > > Sprint 1 has 5 stories which in total is 50 story points. Each story
> > > > > is of size 10 story point.
> > > > > Sprint 2 has 5 stories which in total is 50 story points. Each story
> > > > > is of size 10 story point.
> > > > >
> > > > > Now sprint 1 ends with 3 stories completed and 2 story partially
> > > > > completed( 80 %done). What will be velocity of Sprint 1? I assume it
> > > > > will be 30.
> > > > >
> > > > > Now pending 2 stories are moved to sprint 2. and at the end of sprint
> > > > > 2 , all seven stories are finished( 2 which were moved from Sprint1
> > > > > and 5 Sprint2 stories). So velocity of sprint 2 is 70.
> > > > >
> > > > > How do you explain this difference in velocity to management?
> > > > >
> > > > >
> > > > > Thanks.
> > > > >
> > > >
> > >
> >
>
• I read the blog post and disagree with what I read. If the team worked on the story and didn t complete it, but the story gets re-estimated and the new point
Message 17 of 29 , May 9, 2012
• 0 Attachment

If the team worked on the story and didn't complete it, but the story gets re-estimated and the new point value is lowered because, as the blog author points out, " The amount of work left to do to finish the story is hopefully less than the original estimate. The work remaining to finish the story is the real effort going forward. After all, some of the work is done.", then some amount of work is simply lost -- that is, the differrence between portion of work completed during the current sprint, which isn't counted toward the current sprint because the story wasn't completed, and is now lost because the story is re-estimated and the value lowered to reflect the amount of work remaining.

If I have a 10-point story at the start of sprint n, and the team gets it partially complete, but not Done-Done, and therefore we don't claim it in sprint n, then if we re-estimate the story and realize that there are now only 3 points of work to be completed in sprint n+1, and use that as our new estimate for sprint n+1, where did the other 7 points go? The team did those 7 points of work, but got no credit for them at all.

The point is that the story was a 10 point story and we don't claim credit until all work is completed. The re-estimation of the story ignores this and tries to reassess, but does so at a disservice to the team. The team's velocity shouldn't ignore the 7 points of work that were completed. Ignoring that work is worse than splitting the story, claiming some of the work in sprint n and shifting the rest to sprint n+1.

The team can discuss the work remaining to understand it, but shouldn't need to re-estimate the story to accomplish that....

I disagree with the blog's author that you can't have full credit in the sprint where the work is finally completed. I think that's precisely where you can claim full credit for the originally estimated points, though I welcome discussion on that point.

Bret Wortman

On Wed, May 9, 2012 at 11:14 AM, gopinath wrote:

Mark,

I am not trying to equate story points with duration. Not sure what made it sound otherwise. Sorry if I was not clear enough.

All I am trying to say is - no credit to be given for a partially completed story in Sprint 1. And the work (i.e. in terms of size) which remains in that story has to be treated as a new backlog item, re-prioritized (if necessary) and re-estimated at the beginning of Sprint 2. This will give a closer indication to the size/complexity of the work to be undertaken in Sprint 2.

Not sure whether you went through the link which I had given as reference
http://elegantcode.com/2008/09/16/what-to-do-with-left-over-stories/
This fully describes what I intended to convey.

And yes as you rightly say,time should be spent discussing why the story was not delivered and how to ensure that such occurrences are minimized. This has to be done in during Sprint 1 retrospective.

Gopinath

--- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
>
>
> I have no problem re-estimating stories in the backlog that haven't started.
>
> It sounds like you're trying to equate story points with duration. A story point represents a measure of value/size, not duration. A point point story not delivered is worth nothing to the business. If it's completed on the first day of the next Sprint, then the full value of 5 points is available at the end of the 2nd Sprint when the product is delivered.
>
> Velocity is intended to be a rough planning tool. Spending time re-estimating work in progress is a smell. The time should be spent discussing why the story was not delivered, rather than the amount of effort required to complete it.
>
> Mark
>
>
> --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@> wrote:
> >
> >
> >
> > Mark,
> >
> > I agree with you on "If you re-estimate the stories, the velocity will not reflect their original size."
> >
> > Preserving the information about the original size estimate is one approach. I won't say it is wrong. It may be useful while doing relative estimation.
> >
> > But I tend towards re-prioritizing and re-estimating the unfinished stories in the next Sprint as it reflects the current situation better.
> >
> > This blog post by David Starr explains very clearly why we need to do so:
> > http://elegantcode.com/2008/09/16/what-to-do-with-left-over-stories/
> >
> > Gopinath
> >
> >
> >
> >
> >
> > --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
> > >
> > >
> > > No, that is not correct. The velocity for Sprint 1 will not include the unfinished stories. Thus, the full size of the stories will be part of the velocity calculation for Sprint 2. If you re-estimate the stories, the velocity will not reflect their original size.
> > >
> > > Again, this is the reason many recommend using a rolling average when calculating velocity. A 5 point story that's completed during the first day of the 2nd Sprint will contribute zero points towards the velocity of the first Sprint, and 5 points towards the velocity of the 2nd Sprint, even though there was only a small amount of work remaining.
> > >
> > > Mark
> > >
> > >
> > > --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@> wrote:
> > > >
> > > > I am in agreement with previous responses to this question.
> > > > However at the beginning of Sprint 2 you should re-estimate the story points for the two partially finished stories carried over from Sprint 1.
> > > >
> > > > Gopinath
> > > >
> > > >
> > > > --- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I have a question on velocity.
> > > > >
> > > > > For instance, you have sprint 1 and sprint 2.
> > > > >
> > > > > Sprint 1 has 5 stories which in total is 50 story points. Each story
> > > > > is of size 10 story point.
> > > > > Sprint 2 has 5 stories which in total is 50 story points. Each story
> > > > > is of size 10 story point.
> > > > >
> > > > > Now sprint 1 ends with 3 stories completed and 2 story partially
> > > > > completed( 80 %done). What will be velocity of Sprint 1? I assume it
> > > > > will be 30.
> > > > >
> > > > > Now pending 2 stories are moved to sprint 2. and at the end of sprint
> > > > > 2 , all seven stories are finished( 2 which were moved from Sprint1
> > > > > and 5 Sprint2 stories). So velocity of sprint 2 is 70.
> > > > >
> > > > > How do you explain this difference in velocity to management?
> > > > >
> > > > >
> > > > > Thanks.
> > > > >
> > > >
> > >
> >
>

• Oh man. There s so much so wrong with this whole question. First, I m beginning to think that velocity should be considered a dirty word around here. We
Message 18 of 29 , May 9, 2012
• 0 Attachment
Oh man.  There's so much so wrong with this whole question.

First, I'm beginning to think that "velocity" should be considered a dirty word around here.  We see so many people asking questions and talking about it in ways that clearly indicate that it's being misused.

One point at a time then:

1.  The goal is to look at past performance to determine the correct amount of work for the Team to commit to for the next Sprint.
2.  How much ESTIMATED work was done in Sprint 1?  30 SP worth of completed stories, and 16 worth of uncompleted stories.
3.  How much work should you put into Sprint 2?  I'd aim at about 45 SP, based on past performance, but....
4.  One Sprint is NO WHERE NEAR ENOUGH HISTORICAL DATA to gauge past performance.  So...
5.  Ask the Team what went on.  Ask them if their experience in Sprint 1 would cause them to refine any of their estimates.
6.  Ask the Team how much work they are willing to commit to for Sprint 2.
7.  Your stories are probably too big, if you even have the chance for some of them to be partially completed.  Split them up.
8.  What do you tell management?  Tell them to "Go away and leave the Team alone, it's only Sprint 2".

The Scrum rules say that the Team doesn't get "credit" (whatever the hell that is) for partially completed tasks.  Tasks are either complete or not.  But, velocity isn't really part of Scrum, it's just a tool that Scrumistas use (and is seem even more often, misuse) to help planning.  So you'll want to define it in a way that makes your planning the easiest.  So I'd count partially completed stories for purposes of calculating velocity.  But, if I can be allowed to channel Ron for a moment, if partially completed stories are making you bend your velocity rules, then stop having partially complete stories.

That being said, partially completed stories are something that you want to get rid of.  Re-engineer your planning process to make partially completed stories impossible.

Finally, the whole thing has a smell.  You missed on nearly half the stories in the first Sprint, yet you put even more work into the second Sprint???????  Even smellier, the Team somehow achieved on the bigger second Sprint??????  Bearing in mind that 2 Sprints are way too few to actually identify any patterns or trends, it still looks like there might be some kind of non-Scrum dynamic building in the way work was included in the second Sprint and completed.  Was there pressure applied?  Were the results fudged?  Was the DoD actually met?

Dave Barrett

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 recipient is unauthorized. If you received this e-mail in error, please 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.
• I always struggle with the phrase has to. and its variants. I have seen teams successfully do what you are suggesting and re-estimate their stories. I have
Message 19 of 29 , May 9, 2012
• 0 Attachment

I always struggle with the phrase “has to…” and its variants.  I have seen teams successfully do what you are suggesting and re-estimate their stories.  I have seen just as many teams do what I strongly recommend and keeping the size the same.  They were every bit as successful, maybe a little bit more.

The reason I recommend not re-estimating the work is twofold.  Bret does a great job eloquently explaining why keeping the size the same is valuable, although I oppose the idea of “credit” at any stage of the game.  Mostly, since estimates are of minimal value in the first place, why spend valuable time re-estimating something when we could better be spending that time making software?

From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of gopinath
Sent: Wednesday, May 09, 2012 9:14 AM
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] Re: Velocity Question

Mark,

I am not trying to equate story points with duration. Not sure what made it sound otherwise. Sorry if I was not clear enough.

All I am trying to say is - no credit to be given for a partially completed story in Sprint 1. And the work (i.e. in terms of size) which remains in that story has to be treated as a new backlog item, re-prioritized (if necessary) and re-estimated at the beginning of Sprint 2. This will give a closer indication to the size/complexity of the work to be undertaken in Sprint 2.

Not sure whether you went through the link which I had given as reference
http://elegantcode.com/2008/09/16/what-to-do-with-left-over-stories/
This fully describes what I intended to convey.

And yes as you rightly say,time should be spent discussing why the story was not delivered and how to ensure that such occurrences are minimized. This has to be done in during Sprint 1 retrospective.

Gopinath

--- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
>
>
> I have no problem re-estimating stories in the backlog that haven't started.
>
> It sounds like you're trying to equate story points with duration. A story point represents a measure of value/size, not duration. A point point story not delivered is worth nothing to the business. If it's completed on the first day of the next Sprint, then the full value of 5 points is available at the end of the 2nd Sprint when the product is delivered.
>
> Velocity is intended to be a rough planning tool. Spending time re-estimating work in progress is a smell. The time should be spent discussing why the story was not delivered, rather than the amount of effort required to complete it.
>
> Mark
>
>
> --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@> wrote:
> >
> >
> >
> > Mark,
> >
> > I agree with you on "If you re-estimate the stories, the velocity will not reflect their original size."
> >
> > Preserving the information about the original size estimate is one approach. I won't say it is wrong. It may be useful while doing relative estimation.
> >
> > But I tend towards re-prioritizing and re-estimating the unfinished stories in the next Sprint as it reflects the current situation better.
> >
> > This blog post by David Starr explains very clearly why we need to do so:
> > http://elegantcode.com/2008/09/16/what-to-do-with-left-over-stories/
> >
> > Gopinath
> >
> >
> >
> >
> >
> > --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
> > >
> > >
> > > No, that is not correct. The velocity for Sprint 1 will not include the unfinished stories. Thus, the full size of the stories will be part of the velocity calculation for Sprint 2. If you re-estimate the stories, the velocity will not reflect their original size.
> > >
> > > Again, this is the reason many recommend using a rolling average when calculating velocity. A 5 point story that's completed during the first day of the 2nd Sprint will contribute zero points towards the velocity of the first Sprint, and 5 points towards the velocity of the 2nd Sprint, even though there was only a small amount of work remaining.
> > >
> > > Mark
> > >
> > >
> > > --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@> wrote:
> > > >
> > > > I am in agreement with previous responses to this question.
> > > > However at the beginning of Sprint 2 you should re-estimate the story points for the two partially finished stories carried over from Sprint 1.
> > > >
> > > > Gopinath
> > > >
> > > >
> > > > --- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I have a question on velocity.
> > > > >
> > > > > For instance, you have sprint 1 and sprint 2.
> > > > >
> > > > > Sprint 1 has 5 stories which in total is 50 story points. Each story
> > > > > is of size 10 story point.
> > > > > Sprint 2 has 5 stories which in total is 50 story points. Each story
> > > > > is of size 10 story point.
> > > > >
> > > > > Now sprint 1 ends with 3 stories completed and 2 story partially
> > > > > completed( 80 %done). What will be velocity of Sprint 1? I assume it
> > > > > will be 30.
> > > > >
> > > > > Now pending 2 stories are moved to sprint 2. and at the end of sprint
> > > > > 2 , all seven stories are finished( 2 which were moved from Sprint1
> > > > > and 5 Sprint2 stories). So velocity of sprint 2 is 70.
> > > > >
> > > > > How do you explain this difference in velocity to management?
> > > > >
> > > > >
> > > > > Thanks.
> > > > >
> > > >
> > >
> >
>

• As my mom used to say, You can t have any dessert, because you didn t finish your vegetables. I had a math teacher once who didn t give partial credit. He d
Message 20 of 29 , May 9, 2012
• 0 Attachment
As my mom used to say, "You can't have any dessert, because you didn't finish your vegetables."

I had a math teacher once who didn't give partial credit. He'd claim that almost getting the right answer doesn't help much when the spaceship crashes into the moon's surface.

When you finish your story, you can claim "credit" for delivering value to the business. If the business hands out chocolate sundaes for a completed story, I'm guessing that the team would be motivated to finish a story in the current Sprint. :-)

Frankly, I don't like the term "credit". Again, it smacks too much of gaming the system, with a focus on metrics, rather than delivering value.

Velocity is a rough planning tool. Trying to obtain precision is rather pointless. A running average is sufficient to smooth out the bumps caused by unfinished stories. The emphasis should always be on completing the stories, not getting "credit" for partial work.

Mark

--- In scrumdevelopment@yahoogroups.com, Bret Wortman <bret@...> wrote:
>
> I read the blog post and disagree with what I read.
>
> If the team worked on the story and didn't complete it, but the story gets
> re-estimated and the new point value is lowered because, as the blog author
> points out, " The amount of work left to do to finish the story is
> hopefully less than the original estimate. The work remaining to finish the
> story is the real effort going forward. After all, some of the work is
> done.", then some amount of work is simply lost -- that is, the differrence
> between portion of work completed during the current sprint, which isn't
> counted toward the current sprint because the story wasn't completed, and
> is now lost because the story is re-estimated and the value lowered to
> reflect the amount of work remaining.
>
> If I have a 10-point story at the start of sprint *n*, and the team gets it
> partially complete, but not Done-Done, and therefore we don't claim it in
> sprint *n, *then if we re-estimate the story and realize that there are now
> only 3 points of work to be completed in sprint *n+1*, and use that as our
> new estimate for sprint *n+1*, where did the other 7 points go? The team
> did those 7 points of work, but got no credit for them at all.
>
> The point is that the story was a 10 point story and we don't claim credit
> until all work is completed. The re-estimation of the story ignores this
> and tries to reassess, but does so at a disservice to the team. The team's
> velocity shouldn't ignore the 7 points of work that were completed.
> Ignoring that work is worse than splitting the story, claiming some of the
> work in sprint *n* and shifting the rest to sprint *n+1*.
>
> The team can discuss the work remaining to understand it, but shouldn't
> need to re-estimate the story to accomplish that....
>
> I disagree with the blog's author that you can't have full credit in the
> sprint where the work is finally completed. I think that's precisely where
> you can claim full credit for the originally estimated points, though I
> welcome discussion on that point.
>
>
> *Bret Wortman***
>
>
>
> On Wed, May 9, 2012 at 11:14 AM, gopinath <gopinath_ram@...> wrote:
>
> > **
> >
> >
> >
> >
> > Mark,
> >
> > I am not trying to equate story points with duration. Not sure what made
> > it sound otherwise. Sorry if I was not clear enough.
> >
> > All I am trying to say is - no credit to be given for a partially
> > completed story in Sprint 1. And the work (i.e. in terms of size) which
> > remains in that story has to be treated as a new backlog item,
> > re-prioritized (if necessary) and re-estimated at the beginning of Sprint
> > 2. This will give a closer indication to the size/complexity of the work to
> > be undertaken in Sprint 2.
> >
> > Not sure whether you went through the link which I had given as reference
> > http://elegantcode.com/2008/09/16/what-to-do-with-left-over-stories/
> > This fully describes what I intended to convey.
> >
> > And yes as you rightly say,time should be spent discussing why the story
> > was not delivered and how to ensure that such occurrences are minimized.
> > This has to be done in during Sprint 1 retrospective.
> >
> > Gopinath
> >
> >
> > --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
> > >
> > >
> > > I have no problem re-estimating stories in the backlog that haven't
> > started.
> > >
> > > It sounds like you're trying to equate story points with duration. A
> > story point represents a measure of value/size, not duration. A point point
> > story not delivered is worth nothing to the business. If it's completed on
> > the first day of the next Sprint, then the full value of 5 points is
> > available at the end of the 2nd Sprint when the product is delivered.
> > >
> > > Velocity is intended to be a rough planning tool. Spending time
> > re-estimating work in progress is a smell. The time should be spent
> > discussing why the story was not delivered, rather than the amount of
> > effort required to complete it.
> > >
> > > Mark
> > >
> > >
> > > --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@>
> > wrote:
> > > >
> > > >
> > > >
> > > > Mark,
> > > >
> > > > I agree with you on "If you re-estimate the stories, the velocity will
> > not reflect their original size."
> > > >
> > > > Preserving the information about the original size estimate is one
> > approach. I won't say it is wrong. It may be useful while doing relative
> > estimation.
> > > >
> > > > But I tend towards re-prioritizing and re-estimating the unfinished
> > stories in the next Sprint as it reflects the current situation better.
> > > >
> > > > This blog post by David Starr explains very clearly why we need to do
> > so:
> > > > http://elegantcode.com/2008/09/16/what-to-do-with-left-over-stories/
> > > >
> > > > Gopinath
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
> > > > >
> > > > >
> > > > > No, that is not correct. The velocity for Sprint 1 will not include
> > the unfinished stories. Thus, the full size of the stories will be part of
> > the velocity calculation for Sprint 2. If you re-estimate the stories, the
> > velocity will not reflect their original size.
> > > > >
> > > > > Again, this is the reason many recommend using a rolling average
> > when calculating velocity. A 5 point story that's completed during the
> > first day of the 2nd Sprint will contribute zero points towards the
> > velocity of the first Sprint, and 5 points towards the velocity of the 2nd
> > Sprint, even though there was only a small amount of work remaining.
> > > > >
> > > > > Mark
> > > > >
> > > > >
> > > > > --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@>
> > wrote:
> > > > > >
> > > > > > I am in agreement with previous responses to this question.
> > > > > > However at the beginning of Sprint 2 you should re-estimate the
> > story points for the two partially finished stories carried over from
> > Sprint 1.
> > > > > >
> > > > > > Gopinath
> > > > > >
> > > > > >
> > > > > > --- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@>
> > wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I have a question on velocity.
> > > > > > >
> > > > > > > For instance, you have sprint 1 and sprint 2.
> > > > > > >
> > > > > > > Sprint 1 has 5 stories which in total is 50 story points. Each
> > story
> > > > > > > is of size 10 story point.
> > > > > > > Sprint 2 has 5 stories which in total is 50 story points. Each
> > story
> > > > > > > is of size 10 story point.
> > > > > > >
> > > > > > > Now sprint 1 ends with 3 stories completed and 2 story partially
> > > > > > > completed( 80 %done). What will be velocity of Sprint 1? I
> > assume it
> > > > > > > will be 30.
> > > > > > >
> > > > > > > Now pending 2 stories are moved to sprint 2. and at the end of
> > sprint
> > > > > > > 2 , all seven stories are finished( 2 which were moved from
> > Sprint1
> > > > > > > and 5 Sprint2 stories). So velocity of sprint 2 is 70.
> > > > > > >
> > > > > > > How do you explain this difference in velocity to management?
> > > > > > >
> > > > > > >
> > > > > > > Thanks.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
>
• David, ... get credit (whatever the hell that is) for partially completed tasks. I wasn t aware of this.  Do you have a source for this? The one thing I can
Message 21 of 29 , May 9, 2012
• 0 Attachment
David,

> The Scrum rules say that the Team doesn't get "credit" (whatever the hell that is) for partially completed tasks.

I wasn't aware of this.  Do you have a source for this?

The one thing I can guess at, that you were try to say here is: "Scrum does not consider the time spent working on Sprint Backlog Items.  The work remaining and date are the only variables of interest."

Is that what you were trying to say?

-------
http://www.ScrumCrazy.com

From: David A Barrett <dave.barrett@...>
To: scrumdevelopment@yahoogroups.com
Sent: Wednesday, May 9, 2012 9:47 AM
Subject: [scrumdevelopment] Re: Velocity Question

Oh man.  There's so much so wrong with this whole question.

First, I'm beginning to think that "velocity" should be considered a dirty word around here.  We see so many people asking questions and talking about it in ways that clearly indicate that it's being misused.

One point at a time then:

1.  The goal is to look at past performance to determine the correct amount of work for the Team to commit to for the next Sprint.
2.  How much ESTIMATED work was done in Sprint 1?  30 SP worth of completed stories, and 16 worth of uncompleted stories.
3.  How much work should you put into Sprint 2?  I'd aim at about 45 SP, based on past performance, but....
4.  One Sprint is NO WHERE NEAR ENOUGH HISTORICAL DATA to gauge past performance.  So...
5.  Ask the Team what went on.  Ask them if their experience in Sprint 1 would cause them to refine any of their estimates.
6.  Ask the Team how much work they are willing to commit to for Sprint 2.
7.  Your stories are probably too big, if you even have the chance for some of them to be partially completed.  Split them up.
8.  What do you tell management?  Tell them to "Go away and leave the Team alone, it's only Sprint 2".

The Scrum rules say that the Team doesn't get "credit" (whatever the hell that is) for partially completed tasks.  Tasks are either complete or not.  But, velocity isn't really part of Scrum, it's just a tool that Scrumistas use (and is seem even more often, misuse) to help planning.  So you'll want to define it in a way that makes your planning the easiest.  So I'd count partially completed stories for purposes of calculating velocity.  But, if I can be allowed to channel Ron for a moment, if partially completed stories are making you bend your velocity rules, then stop having partially complete stories.

That being said, partially completed stories are something that you want to get rid of.  Re-engineer your planning process to make partially completed stories impossible.

Finally, the whole thing has a smell.  You missed on nearly half the stories in the first Sprint, yet you put even more work into the second Sprint???????  Even smellier, the Team somehow achieved on the bigger second Sprint??????  Bearing in mind that 2 Sprints are way too few to actually identify any patterns or trends, it still looks like there might be some kind of non-Scrum dynamic building in the way work was included in the second Sprint and completed.  Was there pressure applied?  Were the results fudged?  Was the DoD actually met?

Dave Barrett

• Hi Bret, and all, ... I invented points, and I can tell you that this is not what I had in mind when I did it. Credit for getting things done, vs how hard
Message 22 of 29 , May 9, 2012
• 0 Attachment
Hi Bret, and all,

On May 9, 2012, at 11:35 AM, Bret Wortman wrote:

If I have a 10-point story at the start of sprint n, and the team gets it partially complete, but not Done-Done, and therefore we don't claim it in sprint n, then if we re-estimate the story and realize that there are now only 3 points of work to be completed in sprint n+1, and use that as our new estimate for sprint n+1, where did the other 7 points go? The team did those 7 points of work, but got no credit for them at all.

The point is that the story was a 10 point story and we don't claim credit until all work is completed. The re-estimation of the story ignores this and tries to reassess, but does so at a disservice to the team. The team's velocity shouldn't ignore the 7 points of work that were completed. Ignoring that work is worse than splitting the story, claiming some of the work in sprint n and shifting the rest to sprint n+1.

The team can discuss the work remaining to understand it, but shouldn't need to re-estimate the story to accomplish that....

I disagree with the blog's author that you can't have full credit in the sprint where the work is finally completed. I think that's precisely where you can claim full credit for the originally estimated points, though I welcome discussion on that point.

I invented points, and I can tell you that this is not what I had in mind when I did it.

"Credit" for getting things done, vs how hard they are to do, is simply not the point at all.

In Sprint Planning and execution, there are two things to think about that I would like to address here:

First of all, it is useful for the TEAM to have an idea of how much work to sign up for. At the time points were invented, we were doing this by a thing we called "perfect days", where we thought "if people left us alone to do this, we could do it in n days". People found that the term "days" confused managers and product owners, who would say, five days later, "but you said it would be three days". So we converted days to points in our heads, and said the story was a three point story. Then we paid attention to how many points we did in a Sprint, and used that number to guide how much we would commit to for next time.

PO and management need to know how much work we'll get done over time.

Second, it is THOUGHT TO BE USEFUL for management and the Product Owner to have a sense of how much product they can have done by some future date. (This is nowhere near as useful as it it thought to be, as it is always always evidence of dysfunction if people are very interested in this at all. I'll come back to that.)

Points are only good for one of these two things.

Points are fairly good for deciding how much work to take on.

Stories actually completed per Sprint is fairly good for guessing how much product you'll have by some future date.

THESE ARE NOT THE SAME THING. You cannot reliably use points to decide how much product you'll have. (You can use the number of stories actually completed to guess how many stories will be completed next time: it's just necessary that they all be approximately the same size.)

Manage by results, not by effort

Points represent effort. It is very bad management to value the team in the amount of effort they put in. We do not want effort: we want results.

Finished stories represent results. We should value the team in terms of results, namely in terms of stories.

Claiming credit for points is direct evidence of dysfunction.

The entire exercise of deciding how many points to assign to a story remainder, so as to "claim credit" for the points, tells us that the organization is valuing effort, not results. This is very bad.

Story done? Count it. Story not done? Don't count it.

Need to decide how many stories to commit to? Keep in mind everything you know, and any code that might be useful. This is not about credit, it's about knowing how much work to take on.

Do not confuse planning with promising.
Do not confuse inquisition with improvement.

There's another dysfunction lurking still. The same people who care how many points you do will likely care how many stories you do. They will show this by saying "You PROMISED me ten stories BUT you only did eight! What is wrong with you?"

In Scrum, the purpose of Sprint Planning is to decide how many stories to get completely done, with high quality, by the end of the Sprint. The team can use any means whatsoever to decide how much to take on. The entrails of goats have been used to good effect on some teams, and it it works for you, do it.

Sometimes we do not get done what we thought we could. This is not a matter for comparison of estimates and actuals, much less creative accounting for next time. This is a matter for a whole 'nother part of Scrum, the Retrospective. In the Retrospective, we sit down and say "We thought we'd get ten. We got eight. What happened? What shall we do about it?" There are many possible answers, leading to many possible improvements:

• We got interrupted by (the boss, meetings, ...). Let's reduce interruptions.
• We had to fix a critical defect. Let's bear down on testing and pair programming, so as to reduce defects.
• We got pulled off to work on another project. Let's cancel the Sprint next time, so management will realize they are screwing up their own project.
• We thought Story Six was going to be easy, but we didn't understand it. Let's be sure to get more explicit completion criteria.
• We thought Story Six was going to be easy, but we forgot that it required building new indexes in the database. Let's make a checklist of questions to ask about a feature and make sure database changes are on the list.

Nowhere on this list will we see "we thought it was a seven point story but it turned out to be an eleven", because we can't stop there. We have to say what the four points where that we forgot, and figure out what to do so we won't think we can do what we couldn't do.

Comparing estimates and actuals is weak Scrum at best.

Concern for estimate vs actual is at best an indicator that we need to Inspect and Adapt, and it is not as good an indicator even then as "We thought we could do ten stories and we did only eight", because it requires more analysis to think about it, and it leads us down a line of thinking that is not productive.

Counting stories is easier to do and helps avoid dysfunction.

Therefore, it is best to make stories close enough to the same size so that counting them is a good first cut at guessing what we can do next Sprint. (Then as we plan the Sprint, we consider them in as much more detail as needed. The estimate numbers do not help us with this, so we should not use them.)

Inability to work by counting stories is itself evidence of an impediment.

If we cannot guess how many stories we can do because the team members are specialized and all we can do is add up their individual guesses, we have just identified a major problem: we are not a very well integrated team. We need to learn to talk quickly about a story to give a quick cut at how long it will take.

Don't confuse planning with promising.
Don't confuse improved planning with improved performance.
Don't confuse better estimating cost with producing more value.

When stories do not get done, use the Retrospective to improve how we work rather than call for "better estimates". Continue to use history in Sprint Planning to guess how many to take on next time.

Do not mix the idea of points, and the idea of completed story, together. One is cost, the other is value. Value is more important.

Ron Jeffries
www.XProgramming.com
Sometimes I give myself admirable advice, but I am incapable of taking it.
-- Mary Wortley Montagu

• Thanks, Ron. You know, after I wrote that, the bit about needing to know what to sign up for this sprint was bothering me too, and what I wrote about the team
Message 23 of 29 , May 9, 2012
• 0 Attachment
Thanks, Ron.

You know, after I wrote that, the bit about needing to know what to sign up for this sprint was bothering me too, and what I wrote about "the team needs to discuss it but not re-estimate" was a last minute edit, but I should've waited and pondered more before I pressed the send button on that one.

I don't view "credit" as meaning something we claim when demonstrating value to mangement. I was thinking of it in the sense of understanding how much got accomplished over time, and what I saw was some work getting lost due to the re-estimation. If we do away with velocity (and I'm getting on board with that concept, as I am with doing away with estimation altogether) then I can definitely see where asking the team what still needs to be done, and whether that work fits in with the other stories being considered is a valuable question.

What I objected to was more this idea that any unfinished story needed to have some part of its work ignored, especially when it seemed that so many organizations do value velocity quite highly.

Bret Wortman

On Wed, May 9, 2012 at 1:58 PM, RonJeffries wrote:

Hi Bret, and all,

On May 9, 2012, at 11:35 AM, Bret Wortman wrote:

If I have a 10-point story at the start of sprint n, and the team gets it partially complete, but not Done-Done, and therefore we don't claim it in sprint n, then if we re-estimate the story and realize that there are now only 3 points of work to be completed in sprint n+1, and use that as our new estimate for sprint n+1, where did the other 7 points go? The team did those 7 points of work, but got no credit for them at all.

The point is that the story was a 10 point story and we don't claim credit until all work is completed. The re-estimation of the story ignores this and tries to reassess, but does so at a disservice to the team. The team's velocity shouldn't ignore the 7 points of work that were completed. Ignoring that work is worse than splitting the story, claiming some of the work in sprint n and shifting the rest to sprint n+1.

The team can discuss the work remaining to understand it, but shouldn't need to re-estimate the story to accomplish that....

I disagree with the blog's author that you can't have full credit in the sprint where the work is finally completed. I think that's precisely where you can claim full credit for the originally estimated points, though I welcome discussion on that point.

I invented points, and I can tell you that this is not what I had in mind when I did it.

"Credit" for getting things done, vs how hard they are to do, is simply not the point at all.

In Sprint Planning and execution, there are two things to think about that I would like to address here:

First of all, it is useful for the TEAM to have an idea of how much work to sign up for. At the time points were invented, we were doing this by a thing we called "perfect days", where we thought "if people left us alone to do this, we could do it in n days". People found that the term "days" confused managers and product owners, who would say, five days later, "but you said it would be three days". So we converted days to points in our heads, and said the story was a three point story. Then we paid attention to how many points we did in a Sprint, and used that number to guide how much we would commit to for next time.

PO and management need to know how much work we'll get done over time.

Second, it is THOUGHT TO BE USEFUL for management and the Product Owner to have a sense of how much product they can have done by some future date. (This is nowhere near as useful as it it thought to be, as it is always always evidence of dysfunction if people are very interested in this at all. I'll come back to that.)

Points are only good for one of these two things.

Points are fairly good for deciding how much work to take on.

Stories actually completed per Sprint is fairly good for guessing how much product you'll have by some future date.

THESE ARE NOT THE SAME THING. You cannot reliably use points to decide how much product you'll have. (You can use the number of stories actually completed to guess how many stories will be completed next time: it's just necessary that they all be approximately the same size.)

Manage by results, not by effort

Points represent effort. It is very bad management to value the team in the amount of effort they put in. We do not want effort: we want results.

Finished stories represent results. We should value the team in terms of results, namely in terms of stories.

Claiming credit for points is direct evidence of dysfunction.

The entire exercise of deciding how many points to assign to a story remainder, so as to "claim credit" for the points, tells us that the organization is valuing effort, not results. This is very bad.

Story done? Count it. Story not done? Don't count it.

Need to decide how many stories to commit to? Keep in mind everything you know, and any code that might be useful. This is not about credit, it's about knowing how much work to take on.

Do not confuse planning with promising.
Do not confuse inquisition with improvement.

There's another dysfunction lurking still. The same people who care how many points you do will likely care how many stories you do. They will show this by saying "You PROMISED me ten stories BUT you only did eight! What is wrong with you?"

In Scrum, the purpose of Sprint Planning is to decide how many stories to get completely done, with high quality, by the end of the Sprint. The team can use any means whatsoever to decide how much to take on. The entrails of goats have been used to good effect on some teams, and it it works for you, do it.

Sometimes we do not get done what we thought we could. This is not a matter for comparison of estimates and actuals, much less creative accounting for next time. This is a matter for a whole 'nother part of Scrum, the Retrospective. In the Retrospective, we sit down and say "We thought we'd get ten. We got eight. What happened? What shall we do about it?" There are many possible answers, leading to many possible improvements:

• We got interrupted by (the boss, meetings, ...). Let's reduce interruptions.
• We had to fix a critical defect. Let's bear down on testing and pair programming, so as to reduce defects.
• We got pulled off to work on another project. Let's cancel the Sprint next time, so management will realize they are screwing up their own project.
• We thought Story Six was going to be easy, but we didn't understand it. Let's be sure to get more explicit completion criteria.
• We thought Story Six was going to be easy, but we forgot that it required building new indexes in the database. Let's make a checklist of questions to ask about a feature and make sure database changes are on the list.

Nowhere on this list will we see "we thought it was a seven point story but it turned out to be an eleven", because we can't stop there. We have to say what the four points where that we forgot, and figure out what to do so we won't think we can do what we couldn't do.

Comparing estimates and actuals is weak Scrum at best.

Concern for estimate vs actual is at best an indicator that we need to Inspect and Adapt, and it is not as good an indicator even then as "We thought we could do ten stories and we did only eight", because it requires more analysis to think about it, and it leads us down a line of thinking that is not productive.

Counting stories is easier to do and helps avoid dysfunction.

Therefore, it is best to make stories close enough to the same size so that counting them is a good first cut at guessing what we can do next Sprint. (Then as we plan the Sprint, we consider them in as much more detail as needed. The estimate numbers do not help us with this, so we should not use them.)

Inability to work by counting stories is itself evidence of an impediment.

If we cannot guess how many stories we can do because the team members are specialized and all we can do is add up their individual guesses, we have just identified a major problem: we are not a very well integrated team. We need to learn to talk quickly about a story to give a quick cut at how long it will take.

Don't confuse planning with promising.
Don't confuse improved planning with improved performance.
Don't confuse better estimating cost with producing more value.

When stories do not get done, use the Retrospective to improve how we work rather than call for "better estimates". Continue to use history in Sprint Planning to guess how many to take on next time.

Do not mix the idea of points, and the idea of completed story, together. One is cost, the other is value. Value is more important.

Ron Jeffries
www.XProgramming.com
Sometimes I give myself admirable advice, but I am incapable of taking it.
-- Mary Wortley Montagu

• Just when I thought this thread was getting to long, Ron posts this excellent treatise. Thank you, Ron! Alan ... Just when I thought this thread was getting to
Message 24 of 29 , May 9, 2012
• 0 Attachment
Just when I thought this thread was getting to long, Ron posts this excellent treatise.

Thank you, Ron!

Alan

On May 9, 2012, at 10:58 AM, RonJeffries <ronjeffries@...> wrote:

Hi Bret, and all,

On May 9, 2012, at 11:35 AM, Bret Wortman wrote:

If I have a 10-point story at the start of sprint n, and the team gets it partially complete, but not Done-Done, and therefore we don't claim it in sprint n, then if we re-estimate the story and realize that there are now only 3 points of work to be completed in sprint n+1, and use that as our new estimate for sprint n+1, where did the other 7 points go? The team did those 7 points of work, but got no credit for them at all.

The point is that the story was a 10 point story and we don't claim credit until all work is completed. The re-estimation of the story ignores this and tries to reassess, but does so at a disservice to the team. The team's velocity shouldn't ignore the 7 points of work that were completed. Ignoring that work is worse than splitting the story, claiming some of the work in sprint n and shifting the rest to sprint n+1.

The team can discuss the work remaining to understand it, but shouldn't need to re-estimate the story to accomplish that....

I disagree with the blog's author that you can't have full credit in the sprint where the work is finally completed. I think that's precisely where you can claim full credit for the originally estimated points, though I welcome discussion on that point.

I invented points, and I can tell you that this is not what I had in mind when I did it.

"Credit" for getting things done, vs how hard they are to do, is simply not the point at all.

In Sprint Planning and execution, there are two things to think about that I would like to address here:

First of all, it is useful for the TEAM to have an idea of how much work to sign up for. At the time points were invented, we were doing this by a thing we called "perfect days", where we thought "if people left us alone to do this, we could do it in n days". People found that the term "days" confused managers and product owners, who would say, five days later, "but you said it would be three days". So we converted days to points in our heads, and said the story was a three point story. Then we paid attention to how many points we did in a Sprint, and used that number to guide how much we would commit to for next time.

PO and management need to know how much work we'll get done over time.

Second, it is THOUGHT TO BE USEFUL for management and the Product Owner to have a sense of how much product they can have done by some future date. (This is nowhere near as useful as it it thought to be, as it is always always evidence of dysfunction if people are very interested in this at all. I'll come back to that.)

Points are only good for one of these two things.

Points are fairly good for deciding how much work to take on.

Stories actually completed per Sprint is fairly good for guessing how much product you'll have by some future date.

THESE ARE NOT THE SAME THING. You cannot reliably use points to decide how much product you'll have. (You can use the number of stories actually completed to guess how many stories will be completed next time: it's just necessary that they all be approximately the same size.)

Manage by results, not by effort

Points represent effort. It is very bad management to value the team in the amount of effort they put in. We do not want effort: we want results.

Finished stories represent results. We should value the team in terms of results, namely in terms of stories.

Claiming credit for points is direct evidence of dysfunction.

The entire exercise of deciding how many points to assign to a story remainder, so as to "claim credit" for the points, tells us that the organization is valuing effort, not results. This is very bad.

Story done? Count it. Story not done? Don't count it.

Need to decide how many stories to commit to? Keep in mind everything you know, and any code that might be useful. This is not about credit, it's about knowing how much work to take on.

Do not confuse planning with promising.
Do not confuse inquisition with improvement.

There's another dysfunction lurking still. The same people who care how many points you do will likely care how many stories you do. They will show this by saying "You PROMISED me ten stories BUT you only did eight! What is wrong with you?"

In Scrum, the purpose of Sprint Planning is to decide how many stories to get completely done, with high quality, by the end of the Sprint. The team can use any means whatsoever to decide how much to take on. The entrails of goats have been used to good effect on some teams, and it it works for you, do it.

Sometimes we do not get done what we thought we could. This is not a matter for comparison of estimates and actuals, much less creative accounting for next time. This is a matter for a whole 'nother part of Scrum, the Retrospective. In the Retrospective, we sit down and say "We thought we'd get ten. We got eight. What happened? What shall we do about it?" There are many possible answers, leading to many possible improvements:

• We got interrupted by (the boss, meetings, ...). Let's reduce interruptions.
• We had to fix a critical defect. Let's bear down on testing and pair programming, so as to reduce defects.
• We got pulled off to work on another project. Let's cancel the Sprint next time, so management will realize they are screwing up their own project.
• We thought Story Six was going to be easy, but we didn't understand it. Let's be sure to get more explicit completion criteria.
• We thought Story Six was going to be easy, but we forgot that it required building new indexes in the database. Let's make a checklist of questions to ask about a feature and make sure database changes are on the list.

Nowhere on this list will we see "we thought it was a seven point story but it turned out to be an eleven", because we can't stop there. We have to say what the four points where that we forgot, and figure out what to do so we won't think we can do what we couldn't do.

Comparing estimates and actuals is weak Scrum at best.

Concern for estimate vs actual is at best an indicator that we need to Inspect and Adapt, and it is not as good an indicator even then as "We thought we could do ten stories and we did only eight", because it requires more analysis to think about it, and it leads us down a line of thinking that is not productive.

Counting stories is easier to do and helps avoid dysfunction.

Therefore, it is best to make stories close enough to the same size so that counting them is a good first cut at guessing what we can do next Sprint. (Then as we plan the Sprint, we consider them in as much more detail as needed. The estimate numbers do not help us with this, so we should not use them.)

Inability to work by counting stories is itself evidence of an impediment.

If we cannot guess how many stories we can do because the team members are specialized and all we can do is add up their individual guesses, we have just identified a major problem: we are not a very well integrated team. We need to learn to talk quickly about a story to give a quick cut at how long it will take.

Don't confuse planning with promising.
Don't confuse improved planning with improved performance.
Don't confuse better estimating cost with producing more value.

When stories do not get done, use the Retrospective to improve how we work rather than call for "better estimates". Continue to use history in Sprint Planning to guess how many to take on next time.

Do not mix the idea of points, and the idea of completed story, together. One is cost, the other is value. Value is more important.

Ron Jeffries
www.XProgramming.com
Sometimes I give myself admirable advice, but I am incapable of taking it.
-- Mary Wortley Montagu

• +1 Ron -- Thank you for taking the time to post a thoughtful and insightful response.   ... Charles Bradley http://www.ScrumCrazy.com ... +1 Ron -- Thank you
Message 25 of 29 , May 9, 2012
• 0 Attachment
+1 Ron -- Thank you for taking the time to post a thoughtful and insightful response.

-------
http://www.ScrumCrazy.com

From: Alan Dayley <alandd@...>
To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
Cc: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
Sent: Wednesday, May 9, 2012 1:14 PM
Subject: Re: [scrumdevelopment] Re: Velocity Question

Just when I thought this thread was getting to long, Ron posts this excellent treatise.

Thank you, Ron!

Alan

On May 9, 2012, at 10:58 AM, RonJeffries <ronjeffries@...> wrote:

Hi Bret, and all,

On May 9, 2012, at 11:35 AM, Bret Wortman wrote:

If I have a 10-point story at the start of sprint n, and the team gets it partially complete, but not Done-Done, and therefore we don't claim it in sprint n, then if we re-estimate the story and realize that there are now only 3 points of work to be completed in sprint n+1, and use that as our new estimate for sprint n+1, where did the other 7 points go? The team did those 7 points of work, but got no credit for them at all.

The point is that the story was a 10 point story and we don't claim credit until all work is completed. The re-estimation of the story ignores this and tries to reassess, but does so at a disservice to the team. The team's velocity shouldn't ignore the 7 points of work that were completed. Ignoring that work is worse than splitting the story, claiming some of the work in sprint n and shifting the rest to sprint n+1.

The team can discuss the work remaining to understand it, but shouldn't need to re-estimate the story to accomplish that....

I disagree with the blog's author that you can't have full credit in the sprint where the work is finally completed. I think that's precisely where you can claim full credit for the originally estimated points, though I welcome discussion on that point.

I invented points, and I can tell you that this is not what I had in mind when I did it.

"Credit" for getting things done, vs how hard they are to do, is simply not the point at all.

In Sprint Planning and execution, there are two things to think about that I would like to address here:

First of all, it is useful for the TEAM to have an idea of how much work to sign up for. At the time points were invented, we were doing this by a thing we called "perfect days", where we thought "if people left us alone to do this, we could do it in n days". People found that the term "days" confused managers and product owners, who would say, five days later, "but you said it would be three days". So we converted days to points in our heads, and said the story was a three point story. Then we paid attention to how many points we did in a Sprint, and used that number to guide how much we would commit to for next time.

PO and management need to know how much work we'll get done over time.

Second, it is THOUGHT TO BE USEFUL for management and the Product Owner to have a sense of how much product they can have done by some future date. (This is nowhere near as useful as it it thought to be, as it is always always evidence of dysfunction if people are very interested in this at all. I'll come back to that.)

Points are only good for one of these two things.

Points are fairly good for deciding how much work to take on.

Stories actually completed per Sprint is fairly good for guessing how much product you'll have by some future date.

THESE ARE NOT THE SAME THING. You cannot reliably use points to decide how much product you'll have. (You can use the number of stories actually completed to guess how many stories will be completed next time: it's just necessary that they all be approximately the same size.)

Manage by results, not by effort

Points represent effort. It is very bad management to value the team in the amount of effort they put in. We do not want effort: we want results.

Finished stories represent results. We should value the team in terms of results, namely in terms of stories.

Claiming credit for points is direct evidence of dysfunction.

The entire exercise of deciding how many points to assign to a story remainder, so as to "claim credit" for the points, tells us that the organization is valuing effort, not results. This is very bad.

Story done? Count it. Story not done? Don't count it.

Need to decide how many stories to commit to? Keep in mind everything you know, and any code that might be useful. This is not about credit, it's about knowing how much work to take on.

Do not confuse planning with promising.
Do not confuse inquisition with improvement.

There's another dysfunction lurking still. The same people who care how many points you do will likely care how many stories you do. They will show this by saying "You PROMISED me ten stories BUT you only did eight! What is wrong with you?"

In Scrum, the purpose of Sprint Planning is to decide how many stories to get completely done, with high quality, by the end of the Sprint. The team can use any means whatsoever to decide how much to take on. The entrails of goats have been used to good effect on some teams, and it it works for you, do it.

Sometimes we do not get done what we thought we could. This is not a matter for comparison of estimates and actuals, much less creative accounting for next time. This is a matter for a whole 'nother part of Scrum, the Retrospective. In the Retrospective, we sit down and say "We thought we'd get ten. We got eight. What happened? What shall we do about it?" There are many possible answers, leading to many possible improvements:

• We got interrupted by (the boss, meetings, ...). Let's reduce interruptions.
• We had to fix a critical defect. Let's bear down on testing and pair programming, so as to reduce defects.
• We got pulled off to work on another project. Let's cancel the Sprint next time, so management will realize they are screwing up their own project.
• We thought Story Six was going to be easy, but we didn't understand it. Let's be sure to get more explicit completion criteria.
• We thought Story Six was going to be easy, but we forgot that it required building new indexes in the database. Let's make a checklist of questions to ask about a feature and make sure database changes are on the list.

Nowhere on this list will we see "we thought it was a seven point story but it turned out to be an eleven", because we can't stop there. We have to say what the four points where that we forgot, and figure out what to do so we won't think we can do what we couldn't do.

Comparing estimates and actuals is weak Scrum at best.

Concern for estimate vs actual is at best an indicator that we need to Inspect and Adapt, and it is not as good an indicator even then as "We thought we could do ten stories and we did only eight", because it requires more analysis to think about it, and it leads us down a line of thinking that is not productive.

Counting stories is easier to do and helps avoid dysfunction.

Therefore, it is best to make stories close enough to the same size so that counting them is a good first cut at guessing what we can do next Sprint. (Then as we plan the Sprint, we consider them in as much more detail as needed. The estimate numbers do not help us with this, so we should not use them.)

Inability to work by counting stories is itself evidence of an impediment.

If we cannot guess how many stories we can do because the team members are specialized and all we can do is add up their individual guesses, we have just identified a major problem: we are not a very well integrated team. We need to learn to talk quickly about a story to give a quick cut at how long it will take.

Don't confuse planning with promising.
Don't confuse improved planning with improved performance.
Don't confuse better estimating cost with producing more value.

When stories do not get done, use the Retrospective to improve how we work rather than call for "better estimates". Continue to use history in Sprint Planning to guess how many to take on next time.

Do not mix the idea of points, and the idea of completed story, together. One is cost, the other is value. Value is more important.

Ron Jeffries
www.XProgramming.com
Sometimes I give myself admirable advice, but I am incapable of taking it.
-- Mary Wortley Montagu

• I use a moving average for velocity. It works best. Pick moving average across 3 or 4 sprints. Cheers Jack www.agilebuddy.com
Message 26 of 29 , May 9, 2012
• 0 Attachment
I use a moving average for velocity. It works best. Pick moving average across 3 or 4 sprints.

Cheers
Jack
www.agilebuddy.com

--- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@...> wrote:
>
> Hi,
>
> I have a question on velocity.
>
> For instance, you have sprint 1 and sprint 2.
>
> Sprint 1 has 5 stories which in total is 50 story points. Each story
> is of size 10 story point.
> Sprint 2 has 5 stories which in total is 50 story points. Each story
> is of size 10 story point.
>
> Now sprint 1 ends with 3 stories completed and 2 story partially
> completed( 80 %done). What will be velocity of Sprint 1? I assume it
> will be 30.
>
> Now pending 2 stories are moved to sprint 2. and at the end of sprint
> 2 , all seven stories are finished( 2 which were moved from Sprint1
> and 5 Sprint2 stories). So velocity of sprint 2 is 70.
>
> How do you explain this difference in velocity to management?
>
>
> Thanks.
>
Your message has been successfully submitted and would be delivered to recipients shortly.