Re: [scrumdevelopment] Re: Should I assign Story Points to bugs?
- Hello, Roy. On Friday, January 14, 2011, at 3:33:44 AM, you wrote:
> If we don't think this way, then velocity becomes a measure ofYes. The work of fixing defects distorts the picture of progress. It
> what we have achieved, and what we are likely to be able to
> achieve, ignoring the work needed to fix bugs. Which is certainly
> going to distort estimates of completion dates.
slows us down.
The solution is not to measure it and estimate this work. The
solution is to eliminate it.
>Defects are not a "fact of life". They do not drop as the gentle
> I can't see why there is this opposition to counting work done to
> fix bugs as part of the teams achievements. Bugs are a fact of
> life, even when we try to reduce them towards zero, and bugs take
> time to fix, and therefore affect how much the team achieves in
> deliverable work.
rain upon the code beneath. Each defect is the result of flawed work
-- mistakes -- on the parts of one or more people. Each defect is
capable of being made less probable -- very likely 10x to 100x less
probable -- by the specific ways the team works. See me after class
for a list of some of the ways that are particularly helpful.
Scrum requires that the team produce a //shippable// increment of
code in every Sprint. Not every few Sprints, not after five really
grueling Sprints at the end of the project. Every Sprint.
> Taking the last paragraph of Jack's message as a discussion pointYes. If we spend more time fixing defects, we will deliver fewer
> ... We estimate that the team can deliver 20 Story Points in the
> next Sprint (based on the historically calculated velocity).
> During the sprint we discover some bugs in what we have been
> developing (in the sprint). We fix them because we don't want to
> deliver buggy software. This takes some time and effort. This
> affects our ability to complete all the User Stories. That will
> affect our update of the velocity measure, somehow.
completed stories. Velocity declines due to doing any kind of work
that is not implementing stories. It would also decline if we spend
more hours playing Doom.
End of "Story". Velocity, counted as stories /Done/, correctly
records all forms of wasted time, as well as our general capability,
just by counting the stories.
We are interested in Done stories. We count them as good. We do not
desire defects. If we know during the Sprint that a story we are
working on is defective, we do not demonstrate it, and we do not
count it as done. Our velocity declines immediately, because we
didn't get that one done.
If somehow a story slips out and then a defect is found, that story
has already been recorded in velocity. Velocity is artificially
high. What should we do? One possibility is to reduce our progress
bar by that amount, and insert that story back when and if it is
fixed. That might be more accurate but it is not necessary.
All we do, instead, is count only the stories done next time. Time
spent fixing the broken one does not count. Our progress line drops
by one story, staring now. The line was artificially high for a
while, but now it is back in line.
Note that the defect may take less time than it took to build the
story wrong, or it may take more. Either way, the time necessary to
complete the story correctly, and the number of stories completed,
is back in balance with respect to that story. No estimation is
requiree, no rationalizing about why we should treat what is
obviously waste as if it were somehow a good thing.
Just count what's done. Time spent fixing bugs is waste, and it will
be shown by the amount of work done being reduced.
> If we can still deliver what we selected, then fine, no affect onIf a decision is made to fix a defect, then that decision should be
> velocity. If it does reduce velocity (by a little bit, because
> velocity is essentially a moving average) this merely acknowledges
> that the team achievged a certain amount of work, albeit a little
> less than before. If we find bugs from previous sprints, then we
> must make a decision about fixing them. We acknowledge that some
> bugs are high priority, and some can be left on the queue until
> later. So if we make a User Story of them, and deal with thatn
> User Story in the normal way, we will prioritise bug fixes
> appropriately, and not rush off to fix unimportant bugs, or delay
> fixing important bugs. One way or the other, we will expend work
> time and effort to fix them, which should impact velocity.
handled as if it is a story, that is, it should come in through the
planning session. It should not be accounted for on the product
burndown as if it were new accomplishment, because it isn't new
>-- not what I said, I'm rather sure --
> If I accept Ron's new view, that we make User Stories all of the
> same size, such that they are capable of being completed in 1 day,
> then we still have no great problem here. If a few small bugs areI really don't know. Here's an attempt:
> found, they can be grouped into a User Story that will take 1 day
> to be done. A big bug may need a lot more analysis and be split
> into more than one User Story. Ron's 'new view' is just another
> way of calculating velocity, in my view.
> Again, I ask, where is the problem?
Extreme Programming, specifically the C3 project, specifically Ron,
Chet, and Ann, introduced the notion of velocity in Extreme
Programming Installed, ca. 2000 C.E.
We invented it. We're here to tell you what it is, and why it is
what it is.
Velocity is /defined/ as the number of stories the team completes
per unit time. The notion is specifically designed not to be "the
amount of work" the team completes, because the focus should be on
what the customer (product owner) wants.
(It is perhaps worth mentioning here as well, that "story" is an
idea from XP also. A story is something that the customer (PO)
wants in the system. A feature. Somewhat like a PBI.)
We use velocity for two purposes, once of which is primary: Project
Project Velocity is the rate, in stories per week or equivalent, at
which the team is producing done stories.
In XP, mind you, all stories have complete unit tests and
automated acceptance tests. They are really done. And when, as
inevitably happens, a defect slips through, an XP team examines
its process and practices, determines what tests and other actions
would have prevented that defect, writes those tests, takes those
actions, and ups its game.
They do this because velocity is a measure of //done stories//,
and anything less makes it a measure of stories that may or may
not be done. That's not as useful a measure.
Project Velocity = stories per unit time. Punct, Schluss, Neue Absatz.
There is another slightly useful application for velocity, the
number of stories done: it can be used as part of making the team's
commitment for the upcoming Sprint.
We should note here that Scrum does not ask the team to attain some
velocity. Scrum asks the team to //commit// to the Sprint backlog.
You can use the amount of stories done in the past as part of
deciding how much to commit to. It is not wise to treat this number
as a large component of the decision, as there are many more
influences on how much work the team will get done.
In Sprint planning, velocity is therefore only somewhat useful, if
it is useful at all.
Now then. You express repeated concern that somehow, fixing defects
is a good thing and needs to be taken into account in velocity. The,
pardon the expression, error in this thinking is that fixing defects
is //already// taken into account in velocity, that is, the number
of stories done.
It is trivially true that if the team is working on a lot of bugs,
then they won't get many new stories done. In such a Sprint, their
project velocity will go down, and it should go down, because they
are progressing more slowly toward whatever the sum total of
features needed for release may be.
Velocity already includes work spent fixing defects. It also
includes time spent playing Doom, or snuggling in the closet.
Velocity is the work actually done.
Therefore no other activity, no matter how important, can be treated as
adding to velocity. Counting any other activity makes the measure of
true progress, stories completed, worse, not better.
Velocity is stories done per unit time. And that's all there is.
------- Pause to Breathe, and Think --------
Now then. We might ask "shouldn't we account for the time spent
doing other things, like fixing defects?" Perhaps we should: it's
sometimes useful. We should also, perhaps, account for time spent in
all hands meetings, or working on Project Beta instead of this
Sure. If it's significant, account for it. I like a swim lane
diagram for that, or a bar chart.
Still, none of this other work is "stories". None of it. Yes, it's
important. Yes, we might want to account for it. It might be useful.
But it's not stories, and therefore it isn't velocity.
Logic is overrated as a system of thought.
Although, this is not Twitter. I really want to do a +1.>>It (and the length of this thread) is a great illustration of why I recommend that teams not get too wrapped up in estimation. They start looking for numerical precision, and that starts consuming the energy that could be put toward accomplish goals.
Echoes my thoughts completely. Won't have been able to put it better myself.