Sorry, an error occurred while loading the content.

## The velocity of the team...

Expand Messages
• Hello Scrum Community, I would like to get some help to question I started to wonder when our Scrum Team did not meet the Scrum Goal. What is the velocity of
Message 1 of 28 , Feb 12, 2008
Hello Scrum Community,

I would like to get some help to question I started to wonder when our Scrum Team did not meet the Scrum Goal. What is the velocity of the team if the team cannot finalize all tasks during the sprint. As an example team commits to implemented x product backlog items (user stories) estimated totally 35 story points. Now end of the sprint there are undone tasks so that user stories A (8 story points) and B (3 story points) are partly done. The velocity is then 24 story points or is it? Or should those two user stories re-estimate to get understanding what has been done like user story A: 5 story points were done and rest will be moved to next sprint (and B: 1 points done, 2 undone). Then velocity could be 29 story points.

By summing this up, what is the velocity for team which does not meet the sprint goal (undone tasks)?

Br,

-TT-

Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
• ... In your example the velocity is 24. Scrum recognizes only two degrees of Done : - Done (100%), and - not Done (0%) There is no such thing as almost
Message 2 of 28 , Feb 12, 2008
> By summing this up, what is the velocity for team which does not
> meet the sprint goal (undone tasks)?

In your example the velocity is 24.

Scrum recognizes only two degrees of "Done":
- Done (100%), and
- not Done (0%)

There is no such thing as "almost Done", "partially Done" or "a
little Done". When figuring velocity, the team will do well to count
the points only for items that are completely Done.

The team owns the definition of "Done". A good rule of thumb for
figuring out if the definition of "Done" is a good one is to see what
happens after an item is declared "Done". If there is any more work
afterwards that someone invests in the same item, then the team's
definition of "Done" is broken and needs improvement.

"Oh yes it's done. I just need to document it now". That is not a
proper Done. Either change the definition so that "documented" is
part of what Done means, or systematically add "Document X" items to
the backlog. Ditto for "I just need to refactor", "I just need to
debug it", and so on.

Laurent Bossavit
laurent@...
• ... You said it! My own view is here: http://danube.com/blog/michaeljames/just_say_no_to_partial_credit.html ... How about we say the team negotiates it with
Message 3 of 28 , Feb 12, 2008
--- In scrumdevelopment@yahoogroups.com, Laurent Bossavit <laurent@...> wrote:
>
> There is no such thing as "almost Done", "partially Done" or "a
> little Done". When figuring velocity, the team will do well to count
> the points only for items that are completely Done.

You said it!

My own view is here:
http://danube.com/blog/michaeljames/just_say_no_to_partial_credit.html

>
> The team owns the definition of "Done".

How about we say the team negotiates it with the Product Owner?

--mj
• While I agree in general with what Laurent writes, I have been noticing lately very many teams declaring done when it is not ready to ship; and at the same
Message 4 of 28 , Feb 12, 2008
While I agree in general with what Laurent writes, I have been
noticing lately very many teams declaring "done" when it is not ready
to ship; and at the same time the iteration/sprint length is too
short to really get "done" in any meaningful way.

More generally, I accept that there are times and places (lots of
them in fact), when "end of the sprint" appropriately produces a
result less than "shippable" (Laurent's "done"). This is not a
violation of Scrum - the original description Ken Schwaber gave of
end-of-sprint was a demo!

The question meaningfully becomes, supposing there is a legal and
valid difference between "end-of-sprint done" and "shippable", what
to do about it.

In http://alistair.cockburn.us/index.php/Three_cards_for_user_rights
(the section is http://tinyurl.com/2knmbd), I offer a simple
technique for managing the difference.

However, more interesting than the technique is the (absence of)
dialog inside the company, and the ripple effects.
1) Most companies never notice the difference between "end-of-sprint
done" and "shippable", so they never talk about it.
2) Most programmers don't have any idea how much work it takes to get
from "end-of-sprint done" and "shippable", so neither they nor their
managers schedule it!
3) Following from (2), there isn't an orchestrated dialog between the
parties as to how to schedule and evaluate the allegedly-shippable
version.

Obviously, people and projects slip around a lot on this issue.

The best is to do as Laurent writes, and (a) make the sprints long
enough that
(a) users can see and correct the feature within the sprint period,
(b) everyone can get the feature fully shippable, consumer-grade (or
whatever you need), within the sprint period.

It simplifies discussion and planning a lot.

Alistair

--- In scrumdevelopment@yahoogroups.com, Laurent Bossavit
<laurent@...> wrote:
>
> > By summing this up, what is the velocity for team which does not
> > meet the sprint goal (undone tasks)?
>
>
> In your example the velocity is 24.
>
> Scrum recognizes only two degrees of "Done":
> - Done (100%), and
> - not Done (0%)
>
> There is no such thing as "almost Done", "partially Done" or "a
> little Done". When figuring velocity, the team will do well to
count
> the points only for items that are completely Done.
>
> The team owns the definition of "Done". A good rule of thumb for
> figuring out if the definition of "Done" is a good one is to see
what
> happens after an item is declared "Done". If there is any more
work
> afterwards that someone invests in the same item, then the team's
> definition of "Done" is broken and needs improvement.
>
> "Oh yes it's done. I just need to document it now". That is not a
> proper Done. Either change the definition so that "documented" is
> part of what Done means, or systematically add "Document X" items
to
> the backlog. Ditto for "I just need to refactor", "I just need to
> debug it", and so on.
>
> Laurent Bossavit
> laurent@...
>
• ... In our company we formally recognize 3 phases of development (this is independent of the use of agile techniques). Code Development , Hardening , and
Message 5 of 28 , Feb 12, 2008
> 1) Most companies never notice the difference between "end-of-sprint
> done" and "shippable", so they never talk about it.

In our company we formally recognize 3 phases of development (this is
independent of the use of agile techniques).

"Code Development", "Hardening", and "Final acceptance by the program"

Basically we do our development against prototype hardware, or "early
production" hardware. When we think we have the feature content in, we
go to a phase where all features are declared "done", and only "bug
fixes" are accepted into the release.

At some point in time the bug fixes largely subside, and the program
starts taking the software/hardware to prepare everything for a
world-wide launch.

We'll get more bugs at this phase too, but not in large numbers.

When we started to apply agile techniques, one of our goals was to
reduce the length of the middle phase ('hardening"). We consider it
mainly waste, and it sucks up a lot of time (typically 1 to 1.5 times
the length of the "code development" phase.

There is not much we can do about the last phase (as that is governed by
lots of other considerations including training, documentation,
manufacturing, other software development organizations, etc).

For us, "done" ultimately means that our acceptance tests verify that
the new functionality works (no bugs), and doesn't break anything else
(no regression).

"Shippable" is what happens at the end of the third phase, and it is not
possible (practical) in our current organization/funding structure /
legacy code / manufacturing / hardware dependencies/etc to incorporate
that definition of "done" into every iteration.

We aren't delusional in thinking we can completely eliminate the idea of
"hardening". But steady consistent reduction over time is the goal.

Mike
• I have three definitions of done for a release: feature complete, code complete, and shippable. These roughly correspond to yours, as well...Each of these
Message 6 of 28 , Feb 12, 2008
I have three definitions of done for a release: feature complete, code
complete, and shippable. These roughly correspond to yours, as
well...Each of these definitions is subjective, and belong to the PO. In
any case, the stories and sprints that one actually does to get there
have their own objective definitions of done, and this definition is
negotiated between the PO and the team.

Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
dan@..., 425-269-8628

mpkirby wrote:
>
> > 1) Most companies never notice the difference between "end-of-sprint
> > done" and "shippable", so they never talk about it.
>
> In our company we formally recognize 3 phases of development (this is
> independent of the use of agile techniques).
>
> "Code Development", "Hardening", and "Final acceptance by the program"
>
> Basically we do our development against prototype hardware, or "early
> production" hardware. When we think we have the feature content in, we
> go to a phase where all features are declared "done", and only "bug
> fixes" are accepted into the release.
>
> At some point in time the bug fixes largely subside, and the program
> starts taking the software/hardware to prepare everything for a
> world-wide launch.
>
> We'll get more bugs at this phase too, but not in large numbers.
>
> When we started to apply agile techniques, one of our goals was to
> reduce the length of the middle phase ('hardening"). We consider it
> mainly waste, and it sucks up a lot of time (typically 1 to 1.5 times
> the length of the "code development" phase.
>
> There is not much we can do about the last phase (as that is governed by
> lots of other considerations including training, documentation,
> manufacturing, other software development organizations, etc).
>
> For us, "done" ultimately means that our acceptance tests verify that
> the new functionality works (no bugs), and doesn't break anything else
> (no regression).
>
> "Shippable" is what happens at the end of the third phase, and it is not
> possible (practical) in our current organization/funding structure /
> legacy code / manufacturing / hardware dependencies/etc to incorporate
> that definition of "done" into every iteration.
>
> We aren't delusional in thinking we can completely eliminate the idea of
> "hardening". But steady consistent reduction over time is the goal.
>
> Mike
>
>
• ... Not to play oneupmanship, but we have 4 levels of done... Done Really done! Okay, really, truly done this time. Srsly Production server? and then
Message 7 of 28 , Feb 13, 2008
> I have three definitions of done for a release...

Not to play oneupmanship, but we have 4 levels of done...

"Done"
"Really done!"
"Okay, really, truly done this time.  Srsly"
"Production server?"

and then we have 4 levels of acceptance:

"Okay, looks good"
"What do you mean, run the code?
"Unhandled what?"
"Um, can you define 'Done' again for me? k thx"

Tobias

--- In scrumdevelopment@yahoogroups.com, Dan Rawsthorne <dan.rawsthorne@...> wrote:
>
> I have three definitions of done for a release: feature complete, code
> complete, and shippable. These roughly correspond to yours, as
> well...Each of these definitions is subjective, and belong to the PO. In
> any case, the stories and sprints that one actually does to get there
> have their own objective definitions of done, and this definition is
> negotiated between the PO and the team.
>
> Dan Rawsthorne, PhD, CST
> Senior Coach, Danube Technologies
> dan@..., 425-269-8628
>
>
>
> mpkirby wrote:
> >
> > > 1) Most companies never notice the difference between "end-of-sprint
> > > done" and "shippable", so they never talk about it.
> >
> > In our company we formally recognize 3 phases of development (this is
> > independent of the use of agile techniques).
> >
> > "Code Development", "Hardening", and "Final acceptance by the program"
> >
> > Basically we do our development against prototype hardware, or "early
> > production" hardware. When we think we have the feature content in, we
> > go to a phase where all features are declared "done", and only "bug
> > fixes" are accepted into the release.
> >
> > At some point in time the bug fixes largely subside, and the program
> > starts taking the software/hardware to prepare everything for a
> > world-wide launch.
> >
> > We'll get more bugs at this phase too, but not in large numbers.
> >
> > When we started to apply agile techniques, one of our goals was to
> > reduce the length of the middle phase ('hardening"). We consider it
> > mainly waste, and it sucks up a lot of time (typically 1 to 1.5 times
> > the length of the "code development" phase.
> >
> > There is not much we can do about the last phase (as that is governed by
> > lots of other considerations including training, documentation,
> > manufacturing, other software development organizations, etc).
> >
> > For us, "done" ultimately means that our acceptance tests verify that
> > the new functionality works (no bugs), and doesn't break anything else
> > (no regression).
> >
> > "Shippable" is what happens at the end of the third phase, and it is not
> > possible (practical) in our current organization/funding structure /
> > legacy code / manufacturing / hardware dependencies/etc to incorporate
> > that definition of "done" into every iteration.
> >
> > We aren't delusional in thinking we can completely eliminate the idea of
> > "hardening". But steady consistent reduction over time is the goal.
> >
> > Mike
> >
> >
>
• Another approach, which strikes me as simpler and works for many teams, is to stick to Scrum s classic *potentially shippable product increment*. Potentially
Message 8 of 28 , Feb 13, 2008
Another approach, which strikes me as simpler and works for many teams, is to stick to
Scrum's classic *potentially shippable product increment*. "Potentially shippable" as in
shippable within one stabilization Sprint. Sure it's hard to do, but compromising "done"
beyond this is asking for trouble, IMO.

--mj
• ... teams, is to stick to ... increment*. Potentially shippable as in ... but compromising done ... I don t know how to safely assert the amount of
Message 9 of 28 , Feb 13, 2008
--- In scrumdevelopment@yahoogroups.com, "Michael James"
<michael@...> wrote:
>
> Another approach, which strikes me as simpler and works for many
teams, is to stick to
> Scrum's classic *potentially shippable product
increment*. "Potentially shippable" as in
> shippable within one stabilization Sprint. Sure it's hard to do,
but compromising "done"
> beyond this is asking for trouble, IMO.
>
> --mj
>

I don't know how to safely assert the amount of "nearly shippable"
code that can honestly, truly be made shippable within exactly one
stabilization sprint.

In my experience, people underestimate how long it takes to make
things really ready for shipping.

How do you decide that?

(The even simpler method is the one a few teams do, and Laurent
alluded to --- release to production every single sprint, and then
you'll quickly learn how much you can really fit into a sprint)

Alistair
• ... Yes, exactly. We teach ScrumMasters to expand the definition of done to include all work. What is everyone working on that s more important than the
Message 10 of 28 , Feb 14, 2008
--- In scrumdevelopment@yahoogroups.com, "aacockburn" <acockburn@...> wrote:

> In my experience, people underestimate how long it takes to make
> things really ready for shipping.

Yes, exactly. We teach ScrumMasters to expand the
definition of "done" to include all work.

What is everyone working on that's more important
than the ability to deliver products to customers?
Once we can do that, *then* let's talk about
increasing scope. Unshipped inventory is
waste, and potentially-unshippable inventory
is debt.

>
> How do you decide that?

Typically by guessing wrong, then finding out as
quickly as possible about our wrong guesses.
If it's not truly shippable at the end of our
stabilization Sprint we adapt our definition
of "done" for future Sprints.

In trying, and sometimes failing, we discover
what "potentially shippable product increment"
means for us.

> (The even simpler method is the one a few teams do, and Laurent
> alluded to --- release to production every single sprint, and then
> you'll quickly learn how much you can really fit into a sprint)

I've even heard of teams that claim you could
take their build any given day of the week and
send it out the door (with full testing, user
documents, etc.). Most businesses don't need
to be *that* agile!

--mj
• This is too depressing for management! (The even simpler method is the one a few teams do, and Laurent alluded to --- release to production every single
Message 11 of 28 , Feb 14, 2008
This is too depressing for management!

(The even simpler method is the one a few teams do, and Laurent
alluded to --- release to production every single sprint, and then
you'll quickly learn how much you can really fit into a sprint)

> --- In scrumdevelopment@yahoogroups.com, "aacockburn" <acockburn@...>
> wrote:
>
>> In my experience, people underestimate how long it takes to make
>> things really ready for shipping.
>
> Yes, exactly. We teach ScrumMasters to expand the
> definition of "done" to include all work.
>
> What is everyone working on that's more important
> than the ability to deliver products to customers?
> Once we can do that, *then* let's talk about
> increasing scope. Unshipped inventory is
> waste, and potentially-unshippable inventory
> is debt.
>
>>
>> How do you decide that?
>
> Typically by guessing wrong, then finding out as
> quickly as possible about our wrong guesses.
> If it's not truly shippable at the end of our
> stabilization Sprint we adapt our definition
> of "done" for future Sprints.
>
> In trying, and sometimes failing, we discover
> what "potentially shippable product increment"
> means for us.
>
>
>> (The even simpler method is the one a few teams do, and Laurent
>> alluded to --- release to production every single sprint, and then
>> you'll quickly learn how much you can really fit into a sprint)
>
> I've even heard of teams that claim you could
> take their build any given day of the week and
> send it out the door (with full testing, user
> documents, etc.). Most businesses don't need
> to be *that* agile!
>
> --mj
>
>
• Hi, This is a great thread and topic I run into when working with teams often. It is scary how often this comes up and how people start rationalizing done.
Message 12 of 28 , Feb 14, 2008
Hi,

This is a great thread and topic I run into when working with teams often.  It is scary how often this comes up and how people start "rationalizing" done.

I actually posted a cartoon this week about how teams look at "Done" and you can see more at:

and

Hope they help with starting some conversations!

Thank you,

- Mike Vizdos
CST

Contact Information

On Feb 14, 2008, at 12:56 PM, quinton@... wrote:

This is too depressing for management!

(The even simpler method is the one a few teams do, and Laurent
alluded to --- release to production every single sprint, and then
you'll quickly learn how much you can really fit into a sprint)

> --- In scrumdevelopment@ yahoogroups. com, "aacockburn" <acockburn@. ..>
> wrote:
>
>> In my experience, people underestimate how long it takes to make
>> things really ready for shipping.
>
> Yes, exactly. We teach ScrumMasters to expand the
> definition of "done" to include all work.
>
> What is everyone working on that's more important
> than the ability to deliver products to customers?
> Once we can do that, *then* let's talk about
> increasing scope. Unshipped inventory is
> waste, and potentially- unshippable inventory
> is debt.
>
>>
>> How do you decide that?
>
> Typically by guessing wrong, then finding out as
> quickly as possible about our wrong guesses.
> If it's not truly shippable at the end of our
> stabilization Sprint we adapt our definition
> of "done" for future Sprints.
>
> In trying, and sometimes failing, we discover
> what "potentially shippable product increment"
> means for us.
>
>
>> (The even simpler method is the one a few teams do, and Laurent
>> alluded to --- release to production every single sprint, and then
>> you'll quickly learn how much you can really fit into a sprint)
>
> I've even heard of teams that claim you could
> take their build any given day of the week and
> send it out the door (with full testing, user
> documents, etc.). Most businesses don't need
> to be *that* agile!
>
> --mj
>
>

• ... I ve observed clever mental gymnastics to wiggle out of potentially shippable product increment from people who should know better: demonstrably done (so
Message 13 of 28 , Feb 14, 2008
--- In scrumdevelopment@yahoogroups.com, Mike Vizdos <mvizdos@...> wrote:
> It is scary how often this comes up and how people start "rationalizing" done.
>

I've observed clever mental gymnastics to wiggle out of "potentially
shippable product increment" from people who should know better:
demonstrably done (so we're building demoware????)
as done as *we* can make it (because we're not a cross functional team)
our "product" is a spec (so we're doing waterfall?)

I guess this makes Scrum easier to sell and teach, but modifying
Scrum because it seems too hard robs our clients of growth
opportunities. Rather than succumb to Stockholm syndrome,
let's help reveal those organizational impediments for what
they are.

--mj
• It seems to me that incremental organizational improvement is as important as incremental software development. The real question we should be asking ourselves
Message 14 of 28 , Feb 14, 2008
It seems to me that incremental organizational improvement is as
important as incremental software development.

The real question we should be asking ourselves is that when we settle
for something less than the ideal, what are we going to do next
iteration that gets us closer to that ideal.

If we ultimately settle for mediocrity and decide that it is good
enough, then that culture will permeate everything we do, including our
products.

But there is a big difference between being "half way there" and "good
enough", even though at any given point in time the two organizations
are in the same spot.

Mike

Michael James wrote:
>
> --- In scrumdevelopment@yahoogroups.com, Mike Vizdos <mvizdos@...> wrote:
> > It is scary how often this comes up and how people start
"rationalizing" done.
> >
>
> I've observed clever mental gymnastics to wiggle out of "potentially
> shippable product increment" from people who should know better:
> demonstrably done (so we're building demoware????)
> as done as *we* can make it (because we're not a cross functional team)
> our "product" is a spec (so we're doing waterfall?)
>
> I guess this makes Scrum easier to sell and teach, but modifying
> Scrum because it seems too hard robs our clients of growth
> opportunities. Rather than succumb to Stockholm syndrome,
> let's help reveal those organizational impediments for what
> they are.
• Michael, I love you but I take issue with the denigration of the term demonstrably done . Anything that must be demonstrated, must be demonstrably done. Since
Message 15 of 28 , Feb 14, 2008
Michael, I love you but I take issue with the denigration of the term "demonstrably done". Anything that must be demonstrated, must be demonstrably done. Since all completed work must be demonstrated, all stories must be demonstrably done. This phrase does not imply that done means demonstrable, only that when something is done, it must be demonstrably done. And the phrase "potentially shippable" means nothing to me, since the PO can ship anything he/she wants -- so anything is potentially shippable. Saying that this means that it is something that we would be willing to ship, or that it has the quality we want it to have as if we were shipping it, seems like a tautology to me. Either that, or we're saying to leave quality to the techies -- we're the professionals here -- and this doesn't seem like good teamwork to me

The way I see it, when we claim a story is "done", we should have done two things:
1. achieved the value the story represents in a way that can be demonstrated, and
2. not increased any project risk in the process

This second thing leads to the interesting conversations we are (or should be) having. There are many things involved, but part of the answer is that no technical debt (of any sort) should have increased when a story is "done". This seems (to me) to cover all the arguments we are having about this topic... and it's what my students respond to well. And it leads to real interesting convesations, which should be result of any definitions of this sort, IMHO.
```Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
dan@..., 425-269-8628```
Michael James wrote:

--- In scrumdevelopment@ yahoogroups. com, Mike Vizdos <mvizdos@... > wrote:
> It is scary how often this comes up and how people start "rationalizing" done.
>

I've observed clever mental gymnastics to wiggle out of "potentially
shippable product increment" from people who should know better:
demonstrably done (so we're building demoware???? )
as done as *we* can make it (because we're not a cross functional team)
our "product" is a spec (so we're doing waterfall?)

I guess this makes Scrum easier to sell and teach, but modifying
Scrum because it seems too hard robs our clients of growth
opportunities. Rather than succumb to Stockholm syndrome,
let's help reveal those organizational impediments for what
they are.

--mj

• ... Yes, well said. Potentially shippable product increment is a *target* practice to work towards incrementally. --mj
Message 16 of 28 , Feb 14, 2008
--- In scrumdevelopment@yahoogroups.com, mpkirby <mpkirby@...> wrote:
>
> It seems to me that incremental organizational improvement is as
> important as incremental software development.
>

Yes, well said. "Potentially shippable product increment" is a
*target* practice to work towards incrementally.

--mj
• ... Not half as much as I love you! ... I d call demonstrably done a good start, not a target. Like nightly builds. I think most of us are aware of a huge
Message 17 of 28 , Feb 14, 2008
--- In scrumdevelopment@yahoogroups.com, Dan Rawsthorne <dan.rawsthorne@...> wrote:
>
> Michael, I love you

Not half as much as I love you!

> but I take issue with the denigration of the term
> "demonstrably done".

I'd call "demonstrably done" a good start, not a target.
Like nightly builds.

I think most of us are aware of a huge gulf between
demonstrable and shippable. Ken was on to something
when he wrote "potentially shippable product increment"
about 20 times in the gray book.

--mj
• That s not the point. There is no inconsistency. Demonstrable is a requirement of doneness, not the definition of doneness. The term was first used (by me) to
Message 18 of 28 , Feb 15, 2008
That's not the point. There is no inconsistency. Demonstrable is a
requirement of doneness, not the definition of doneness. The term was
first used (by me) to describe what were appropriate stories, not what
does "done" mean. It comes up in the context like this "a story is
appropriate for a sprint backlog if the story can be demonstrably done;
that is, that the doneness criteria are demonstrable, so that becoming
done is objective, not subjective. Of course, being done (which we are
talking about) is a different thing. Being done means all the stuff we
agree on, but I ADD the requirement that being done must be demonstrable.

Just Sayin'

Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
dan@..., 425-269-8628

Michael James wrote:
>
> --- In scrumdevelopment@yahoogroups.com
> <mailto:scrumdevelopment%40yahoogroups.com>, Dan Rawsthorne
> <dan.rawsthorne@...> wrote:
> >
> > Michael, I love you
>
> Not half as much as I love you!
>
> > but I take issue with the denigration of the term
> > "demonstrably done".
>
> I'd call "demonstrably done" a good start, not a target.
> Like nightly builds.
>
> I think most of us are aware of a huge gulf between
> demonstrable and shippable. Ken was on to something
> when he wrote "potentially shippable product increment"
> about 20 times in the gray book.
>
> --mj
>
>
• ... Oh. Well that makes sense! --mj
Message 19 of 28 , Feb 15, 2008
--- In scrumdevelopment@yahoogroups.com, Dan Rawsthorne <dan.rawsthorne@...> wrote:
>
> That's not the point. There is no inconsistency. Demonstrable is a
> requirement of doneness, not the definition of doneness.

Oh. Well that makes sense!

--mj
• ... Alistair, I think the proper term is potentially shippable rather than shippable . As Jeff Patton is wont to say, You aren t gonna ship it. ...
Message 20 of 28 , Feb 18, 2008
aacockburn wrote:
> While I agree in general with what Laurent writes, I have been
> noticing lately very many teams declaring "done" when it is not ready
> to ship; and at the same time the iteration/sprint length is too
> short to really get "done" in any meaningful way.
>
> More generally, I accept that there are times and places (lots of
> them in fact), when "end of the sprint" appropriately produces a
> result less than "shippable" (Laurent's "done"). This is not a
> violation of Scrum - the original description Ken Schwaber gave of
> end-of-sprint was a demo!

Alistair, I think the proper term is "potentially shippable" rather than
"shippable". As Jeff Patton is wont to say, "You aren't gonna ship it."

> The question meaningfully becomes, supposing there is a legal and
> valid difference between "end-of-sprint done" and "shippable", what
> to do about it.
>
> In http://alistair.cockburn.us/index.php/Three_cards_for_user_rights
> (the section is http://tinyurl.com/2knmbd), I offer a simple
> technique for managing the difference.
>
> However, more interesting than the technique is the (absence of)
> dialog inside the company, and the ripple effects.
> 1) Most companies never notice the difference between "end-of-sprint
> done" and "shippable", so they never talk about it.
> 2) Most programmers don't have any idea how much work it takes to get
> from "end-of-sprint done" and "shippable", so neither they nor their
> managers schedule it!
> 3) Following from (2), there isn't an orchestrated dialog between the
> parties as to how to schedule and evaluate the allegedly-shippable
> version.
[snip]
> Obviously, people and projects slip around a lot on this issue.
>
> The best is to do as Laurent writes, and (a) make the sprints long
> enough that
> (a) users can see and correct the feature within the sprint period,
> (b) everyone can get the feature fully shippable, consumer-grade (or
> whatever you need), within the sprint period.
>
> It simplifies discussion and planning a lot.

I would like to propose an alternative to your first (a): that is, to
become practiced at slicing the functionality into small slivers such
that it can be production quality within a short sprint, rather than
lengthening the sprint.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
• ... I agree. Why is velocity value so important to you (Tomi)? The team didn t deliver the whole committed work. Ok, let s learn why (insert the thread of
Message 21 of 28 , Feb 21, 2008
--- In scrumdevelopment@yahoogroups.com, Laurent Bossavit <laurent@...> wrote:
>
> > By summing this up, what is the velocity for team which does not
> > meet the sprint goal (undone tasks)?
>
>
> In your example the velocity is 24.
>
> Scrum recognizes only two degrees of "Done":
> - Done (100%), and
> - not Done (0%)
>

I agree.

Why is velocity value so important to you (Tomi)?

The team didn't deliver the whole committed work.

Ok, let's learn why (insert the thread of "done" here)

But is it ok to fail, not to often, not to much, maybe (a new thread on common and special causes here :)  )

I sometimes feel that teams overreact to (partial) failure. Some of the things that you learned this "failed" sprint would help you speed up the next one.

For instance, I expect that the definition of done will slowly change over time. If the team fail frequently, it could be a bad "done" definition or bad estimation. If bad estimation is the problem, changing the "done" definition will do more harm.

Juan

• I m probably repeating what was already said but from our team s perspective and mentoring, I regard stories as Done or Not Done. Even if the Not Done is at
Message 22 of 28 , Feb 21, 2008
I'm probably repeating what was already said but from our team's
perspective and mentoring, I regard stories as Done or Not Done. Even
if the Not Done is at 99%, its still going to count as 0 story points
in our burn up chart.

After our sprint, we then see if it makes the priority list for the
next sprint and add accordingly.

As a new team, we are still learning the amount of story points we can
adequetly handle, in our 2nd iteration, we made some mistakes in story
planning but the benefit is we learned from it.

I think the entire thing is a learning process and never ends from
this n00b's pov.
• I agree entirely on the Done/Not Done viewpoint, but I have a concern about that in regard to the calculation of sprint velocity. If we take the worse case
Message 23 of 28 , Feb 22, 2008
I agree entirely on the Done/Not Done viewpoint, but I have a concern about that in regard to the calculation of sprint velocity. If we take the worse case scenario, someone is 99% finished on their one and only task for the sprint. As it is not done, it is 0 story points achieved in the sprint. Where does that leave sprint velocity?

Regards,
Roy Morien

To: scrumdevelopment@yahoogroups.com
From: tpagliocco@...
Date: Fri, 22 Feb 2008 07:54:14 +0000
Subject: [scrumdevelopment] Re: The velocity of the team...

I'm probably repeating what was already said but from our team's
perspective and mentoring, I regard stories as Done or Not Done. Even
if the Not Done is at 99%, its still going to count as 0 story points
in our burn up chart.

After our sprint, we then see if it makes the priority list for the
next sprint and add accordingly.

As a new team, we are still learning the amount of story points we can
adequetly handle, in our 2nd iteration, we made some mistakes in story
planning but the benefit is we learned from it.

I think the entire thing is a learning process and never ends from
this n00b's pov.

Check our comprehensive Salary Centre Overpaid or Underpaid?
• ... Jagged. But it all balances out over time. I m curious as to why you switched the focus to tasks here, and to one person (rather than story and team).
Message 24 of 28 , Feb 22, 2008
> Where does that leave sprint velocity?
Jagged.  But it all balances out over time.

I'm curious as to why you switched the focus to tasks here, and to one person (rather than story and team).

Tobias

--- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@...> wrote:
>
> I agree entirely on the Done/Not Done viewpoint, but I have a concern about that in regard to the calculation of sprint velocity. If we take the worse case scenario, someone is 99% finished on their one and only task for the sprint. As it is not done, it is 0 story points achieved in the sprint. Where does that leave sprint velocity?
>
> Regards,
> Roy Morien
>
>
> To: scrumdevelopment@...: tpagliocco@...: Fri, 22 Feb 2008 07:54:14 +0000Subject: [scrumdevelopment] Re: The velocity of the team...
>
>
>
>
> I'm probably repeating what was already said but from our team'sperspective and mentoring, I regard stories as Done or Not Done. Evenif the Not Done is at 99%, its still going to count as 0 story pointsin our burn up chart. After our sprint, we then see if it makes the priority list for thenext sprint and add accordingly.As a new team, we are still learning the amount of story points we canadequetly handle, in our 2nd iteration, we made some mistakes in storyplanning but the benefit is we learned from it.I think the entire thing is a learning process and never ends fromthis n00b's pov.
>
>
>
>
>
>
> _________________________________________________________________
> Overpaid or Underpaid? Check our comprehensive Salary Centre
> http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fcontent%2Emycareer%2Ecom%2Eau%2Fsalary%2Dcentre%3Fs%5Fcid%3D595810&_t=766724125&_r=Hotmail_Email_Tagline_MyCareer_Oct07&_m=EXT
>
• Sorry, I didn t really switch ... I was just careless with my words. I used task to indicate an activity being undertaken to complete the story
Message 25 of 28 , Feb 23, 2008
Sorry, I didn't really 'switch' ... I was just careless with my words. I used 'task' to indicate an activity being undertaken to complete the story requirements. And I was just thinking of a member of the team not contributing to the velocity calculation because of being 99% progressed, not Done.

Another point comes to mind, partly in answer to my own question. I guess if you have a team of 7, 8, 10 people, and they all were 99% complete, it would indicate a problem with estimating story points. On the other hand, Done by most and 99% complete by some would average out over time. Right?

Regards,
Roy Morien

To: scrumdevelopment@yahoogroups.com
From: tobias.mayer@...
Date: Sat, 23 Feb 2008 04:26:27 +0000
Subject: [scrumdevelopment] Re: The velocity of the team...

> Where does that leave sprint velocity?
Jagged.  But it all balances out over time.

I'm curious as to why you switched the focus to tasks here, and to one person (rather than story and team).

Tobias

--- In scrumdevelopment@ yahoogroups. com, Roy Morien <roymorien@.. .> wrote:
>
> I agree entirely on the Done/Not Done viewpoint, but I have a concern about that in regard to the calculation of sprint velocity. If we take the worse case scenario, someone is 99% finished on their one and only task for the sprint. As it is not done, it is 0 story points achieved in the sprint. Where does that leave sprint velocity?
>
> Regards,
> Roy Morien
>
>
> To: scrumdevelopment@ ...: tpagliocco@. ..: Fri, 22 Feb 2008 07:54:14 +0000Subject: [scrumdevelopment] Re: The velocity of the team...
>
>
>
>
> I'm probably repeating what was already said but from our team'sperspective and mentoring, I regard stories as Done or Not Done. Evenif the Not Done is at 99%, its still going to count as 0 story pointsin our burn up chart. After our sprint, we then see if it makes the priority list for thenext sprint and add accordingly. As a new team, we are still learning the amount of story points we canadequetly handle, in our 2nd iteration, we made some mistakes in storyplanning but the benefit is we learned from it.I think the entire thing is a learning process and never ends fromthis n00b's pov.
>
>
>
>
>
>
> ____________ _________ _________ _________ _________ _________ ________
> Overpaid or Underpaid? Check our comprehensive Salary Centre
> http://a.ninemsn. com.au/b. aspx?URL= http%3A%2F% 2Fcontent% 2Emycareer% 2Ecom%2Eau% 2Fsalary% 2Dcentre% 3Fs%5Fcid% 3D595810&_t=766724125&_r=Hotmail_Email_ Tagline_MyCareer _Oct07&_m=EXT
>

Check our comprehensive Salary Centre Overpaid or Underpaid?
• ... Roy, I would say that the first red flag is raised when there in only one task (or story) in the sprint. That says to me that things are not being broken
Message 26 of 28 , Feb 23, 2008
Roy Morien wrote:
> I agree entirely on the Done/Not Done viewpoint, but I have a concern
> about that in regard to the calculation of sprint velocity. If we take
> the worse case scenario, someone is 99% finished on their one and only
> task for the sprint. As it is not done, it is 0 story points achieved in
> the sprint. Where does that leave sprint velocity?

Roy, I would say that the first red flag is raised when there in only
one task (or story) in the sprint. That says to me that things are not
being broken into small enough piece. I could go into more detail of
the issues, but calculation of sprint velocity is the least of the problems.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
• ... concern ... take ... only ... achieved in ... As initial guideline I believe that stories are either Done or Not-Done. Notion of 99% finished on a task is
Message 27 of 28 , Feb 23, 2008

Roy Morien wrote:

> I agree entirely on the Done/Not Done viewpoint, but I have a concern
> about that in regard to the calculation of sprint velocity. If we take
> the worse case scenario, someone is 99% finished on their one and only
> task for the sprint. As it is not done, it is 0 story points achieved in
> the sprint. Where does that leave sprint velocity?

As initial guideline I believe that stories are either Done or Not-Done.

Notion of 99% finished on a task is very subjective as it depends on teams approach towards task breakdown.

A couple of task break down approaches that I have observed:

a. Tasks along skill boundaries.

Example: code, code review unit tests, system tests etc.. [observed mainly in teams starting with agile s/w development]

b. Tasks along functionality encompassed by user story.

Example: enable search button functionality, enable search using special filters (“+”, “site:” etc) [observed in mature agile teams that follow XP practices]

Key differentiation between above mentioned approaches of task breakdown is that

in approach [a] tasks do not meet definition of done when they are finished, where as

in approach [b] each individual task for the user story is finished when it fulfills definition of done.

Since, Velocity is measure of the amount of work that a scrum team can call as “Done” within a sprint. A team that delivers functionality (code) as potentially shippable software (meets definition of Done) could count a portion of user story size in their velocity.

This is under the assumption that the product owner considers this subset of story as valuable.

So IMHO, if a task is 99% finished and the task is along skill boundaries then the entire story should be considered as Not-Done, since the functionality is not in a potentially shippable state. However, if the last remaining task is 99% done and all other finished tasks represent some functionality for the story then size of remaining functionalities completed for that story can be included in sprint velocity.

I also believe that this accounting complexity should be avoided at all costs. This can be achieved by holding prior conversations with Product Owner and negotiating a split for large or risky user stories prior to sprint completion.

Best Regards,

Sr. Analyst/Agile Coach

CSM (P)

SolutionsIQ

10785 Willows Road NE, Suite 200

Redmond, WA , 98052

cell: 425-283-6184

you must be the change you wish to see in the world - Mahatma Gandhi.

From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of George Dinwiddie
Sent: Saturday, February 23, 2008 5:30 PM
To: scrumdevelopment@yahoogroups.com
Subject: Re: [scrumdevelopment] Re: The velocity of the team...

Roy Morien wrote:

> I agree entirely on the Done/Not Done viewpoint, but I have a concern
> about that in regard to the calculation of sprint velocity. If we take
> the worse case scenario, someone is 99% finished on their one and only
> task for the sprint. As it is not done, it is 0 story points achieved in
> the sprint. Where does that leave sprint velocity?

Roy , I would say that the first red flag is raised when there in only
one task (or story) in the sprint. That says to me that things are not
being broken into small enough piece. I could go into more detail of
the issues, but calculation of sprint velocity is the least of the problems.

- George

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

• Hiya, Nice discussion! I always make a distinction between done and potentially shippable . As MJ says, potentially shippable is the goal is Scrum. To me
Message 28 of 28 , Mar 12, 2008
Hiya,

Nice discussion!

I always make a distinction between "done" and "potentially
shippable". As MJ says, potentially
shippable is the goal is Scrum. To me that would mean, whenever the PO
says "ship it!" then it
would, the next day (or earlier) be at the customer. This means that
an ideal "potentially shippable"
will reach far out the development organization.

"Done" is what the current organization is capable of. In smaller
projects, they are often the same
since it's not too hard to make stuff potentially shippable every
sprint. In large projects, getting
"done" to become "potentially shippable" will require huge changes in
the organization and in
the technology! Thus, "done" is their current capability and from the
day they start Scrum, the
teams goal is to improve and make it the same as potentially
shippable. For very large projects,
that might take years (which is mostly recovering from years and years
of technical dept).

I'd always measure stuff in DONE or NOT DONE as defined by the team
and the PO together.
99% done is not done and thus not included in velocity. I'f even
recommend to make the
"effort remaining" in the product backlog to be the same as the
original.

Bas

On Feb 15, 2008, at 1:53 AM, Michael James wrote:

> --- In scrumdevelopment@yahoogroups.com, mpkirby <mpkirby@...> wrote:
> >
> > It seems to me that incremental organizational improvement is as
> > important as incremental software development.
> >
>
> Yes, well said. "Potentially shippable product increment" is a
> *target* practice to work towards incrementally.
>
> --mj
>
>
>
Your message has been successfully submitted and would be delivered to recipients shortly.