Re: [scrumdevelopment] Re: Scheduling Defect Fixes
- Hello, Roy.
You really do not want to go down the Technical Stories rathole.
Technical stories do not work well. The reason is that the Product
Owner must prioritize all work. It is nearly impossible to compare
the value of a new feature with the value of some proposed
refactoring, or with upgrading the servers to Version 184.108.40.206.
The result of this difficulty is dispute, and, for many teams, great
difficulty in getting "permission" to do technically important
Yet, this work needs to be done. One might ask what we do about it.
Product Owner can understand and prioritize.
Second, we do as much technical work as we can, as a matter of
course. For example, all necessary refactoring to put in a new
feature is done as part of the feature. If we estimate features, we
include all necessary work as part of the estimate. (As would
anyone, I hope.)
The result of this is that there is little or no need for "Technical
Stories". This is a good thing, because it is so difficult to
prioritize them fairly.
One more thing:
On Tuesday, February 1, 2011, at 9:53:13 AM, you
> And by including all of them in velocity (because they all requireActually, we cannot. The reason is that working this way, we do not
> effort to be expended), we can still give an updated estimate of
> completion time, or features that can be completed by the stated
have any way of knowing what Defect Stories, and what Technical
Stories, will pop up. It therefore works better to treat all such
work as overhead, so that our estimates do not have to be rescaled
to accommodate this unknown. Instead, if we count only true User
Stories, velocity predicts directly when all User Stories will be
done. Everything else is factored out of that measure.
(This not to say that we should not track that overhead. We should,
unless it is quite small. I have previously recommended a "swim
lane" diagram for this purpose.) This makes the information visible,
but does not contaminate the progress charts.
> (and we all know this is the bit that varies, sometimesI don't know that. If the completion time or number of features
> wildly, over time).
possible by a date is varying wildly over time, there is something
seriously wrong. Common causes of wide variance in velocity include:
-- changes in team composition;
-- team working on more than one thread of work;
-- late or inadequate testing turns up problems late;
-- high defect injection rate adding unexpected work;
-- decreasing code quality causing variability in effort;
-- and doubtless others.
Each and every one of these makes the Scrum burn charts less useful.
As such, each and every one represents an impediment that needs to
Hope is not a strategy. -- Michael Henos
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.