What does completed mean?
Scott C. Lemon
John Wilger
Th burn-down probably /should/ scare your executives if this is the case!
Most agile practitioners would advise you to think of a story as being
either "done" or "not done"—that is, until it is complete, the story
points should not count towards your progress.
The idea is that burn-down is about more than simply tracking how many
hours you've spent on something. It's also about tracking the value
that has been delivered. Until a story is "done-done", it's not
actually providing value.
If you look into Lean methods, you'll find that partially complete
work is considered one of the greatest evils. It causes you to have a
much higher ratio of effort spent to value delivered; and the longer
something sits in this in-between state, the more likely it is that it
will stagnate and need to be completely reworked before it can be
delivered. Therefore, given a "fixed" date of delivery for a single
product (story, feature, etc.), it is best to start production as late
as possible in order to reduce total work-in-progress at any given
point in time.
From a pragmatic standpoint, I've often found that when a team is
constantly feeling like they need to be able to put a "percent
complete" on a story card, it is because the stories are too big. It's
OK to write these "epic" story cards when you're in the early stages
of planning new features, but it's wise to split them into smaller
stories before they are planned into an iteration.
The idea of "tasks" associated with a story card in XP is intended to
serve as a checklist of technical items that need to be completed in
order to make the functionality of the story work, but which have no
"value" in and of themselves—i.e. your customer doesn't care that you
added a few columns to the database, they only care whether or not
they can see how many widgets were sold in October.
Therefore, you are—of course—free to make the requested change to your
own, forked copy of eXPlainPMT (and I'd even be happy to help you
figure out how to set things up so that you can continue to benefit
from other updates to the official source), but I don't think there
will ever be a per-story %-complete calculation of any form in the
official distribution.
--
Regards,
John Wilger
http://johnwilger.com
-----------
"Quality means doing it right when no one is looking." – Henry Ford
Scott C. Lemon
Thank you for the reply ... And I do agree with the philosophy. Here is our
situation, and how I'm looking to map this into eXPlain ...
Our "customer" is purely internal, and the execs are just looking to get an
idea of how we are making progress. I do understand the "done/not done" and
agree.
We are also using this to look at who, on the development team, is
potentially a critical path. Or more appropriately what tasks. In the case
of our first efforts to use eXPlain, we are finding that most all of the
development is completed, however we are waiting on the graphic designer to
provide the creative artwork to integrate with working functionality. So
buttons, images, or stylesheets.
I'm split between moving these to a completely different story ... Since
they are integral. I'm also wanting a way to quickly view what tasks are
done, not done, and who is not complete on various stories.
I'm not looking to create a new version ... More understand how others are
using eXPlain in their development.
Also ... Is there any way for me - as a manager - to see the outstanding
tasks in an iteration for a particular developer?
Thanks again for the feedback and the great solution! So far ... So good!
Scott C. Lemon
-----Original Message-----
From: explainp...@googlegroups.com
[mailto:explainp...@googlegroups.com] On Behalf Of John Wilger
Sent: Wednesday, August 22, 2007 3:55 PM
To: Scott C. Lemon
Cc: explainp...@googlegroups.com
Subject: Re: What does completed mean?
On 8/22/07, Scott C. Lemon <Scott...@humanxtensions.com> wrote:
> Question: When do the points get counted as "completed"?
>
> Is there *any* way to assign points to a task? This, to me, is very
> important ...
>
> I was used to using XPlanner, where we had points on a story, but they
> were overridden by the total points of all tasks within the story.
> This way we could track progress, even when stories were not 100%
complete.
>
> Right now we have numerous stories that are 95% completed ... but
> waiting on some final creative and graphics. Our burn-down shows that
> *nothing* has been done for a week ... since no story has completed.
> :-(
>
> How do you suggest that we use eXPlain in this situation? The
> burn-down is scaring the executives! :-)
Th burn-down probably /should/ scare your executives if this is the case!
Most agile practitioners would advise you to think of a story as being
either "done" or "not done"--that is, until it is complete, the story points
should not count towards your progress.
The idea is that burn-down is about more than simply tracking how many hours
you've spent on something. It's also about tracking the value that has been
delivered. Until a story is "done-done", it's not actually providing value.
If you look into Lean methods, you'll find that partially complete work is
considered one of the greatest evils. It causes you to have a much higher
ratio of effort spent to value delivered; and the longer something sits in
this in-between state, the more likely it is that it will stagnate and need
to be completely reworked before it can be delivered. Therefore, given a
"fixed" date of delivery for a single product (story, feature, etc.), it is
best to start production as late as possible in order to reduce total
work-in-progress at any given point in time.
From a pragmatic standpoint, I've often found that when a team is constantly
feeling like they need to be able to put a "percent complete" on a story
card, it is because the stories are too big. It's OK to write these "epic"
story cards when you're in the early stages of planning new features, but
it's wise to split them into smaller stories before they are planned into an
iteration.
The idea of "tasks" associated with a story card in XP is intended to serve
as a checklist of technical items that need to be completed in order to make
the functionality of the story work, but which have no "value" in and of
themselves--i.e. your customer doesn't care that you added a few columns to
the database, they only care whether or not they can see how many widgets
were sold in October.
Therefore, you are--of course--free to make the requested change to your
own, forked copy of eXPlainPMT (and I'd even be happy to help you figure out
how to set things up so that you can continue to benefit from other updates
to the official source), but I don't think there will ever be a per-story
%-complete calculation of any form in the official distribution.
--
Regards,
John Wilger
http://johnwilger.com
-----------
"Quality means doing it right when no one is looking." - Henry Ford
Jake Dempsey
In short, eXPlainPMT is a tool for the team to manage the work, not the time it takes to do the work. A story is "done" when it has been accepted by the business and has delivered value. I wish I had more time to write on this, but there have been volumes of posts, blogs, articles, and books on the same topic.....and my wife is asking me to watch a movie with her :)
Jake Dempsey
www.watij.com
www.explainpmt.com
Jake Dempsey
www.watij.com
www.explainpmt.com