RE: [scrumdevelopment] Re: Scheduling Defect Fixes
- Ron, as you well know, iterative, agile, XP etc. methods all include the notion that we Welcome Change, and handle it, by Adaptive Planning, Adaptive Estimating etc. based on what we know now, with the assumption, usually correct, that the future will bring new and different requirements.
Just-in-Time requirements detailing (not requirements determination or requirements discovery) is a good idea because we detail the requirements just in time to be developed, and we are not using old requirements statements that may actually have changed, even if we try not to recognise that, and we call it 'scope creep' and everyone says Ohh, that's bad!
So your comment that "we do not have any way of knowing what Defect Stories, and what Technical Stories, will pop up.", as a justification for doing, or not doing, something, is fallacious. It is correct to say that, yes, but it also applies to other 'user requested' requirements.
This is why the future estimating completion date can vary (ok, not too widly, I hope), or some requirements already identified may end up in the 'probably not by the deadline' category.
I don't want to defend my suggestion about Technical Stories too stoutly, but isn't collaboration, team work, PO on the team stuff part of Scrum, XP and etc.? I would think it is a somewhat dysfunctional situation if the developers explain to the PO that some technical work needs to be done, and the PO refuses to allow it. This seems a little bloody-minded to me, and hardly collaborative and effective team work.
I hark back some months to another controversy we had, when I suggested that the developers would usually have a particular DBMS available that they would use in the project. It was pointed out to me that this was badly not agile. But I stick to my point that there are a lot of 'technical' things that should be in place even before the project starts. So it could be said that the appearance of a technical matter that needs doing in the middle of the project is a result of the team not being fully prepared to start the project. Nonetheless, it might happen (just like defects might be created) and needs to be dealt with.
So what is this 'overhead' that you suggest we track, and how is it factored in to the teams activities? ... which will presumably affect the future delivery dates or achieveable functionality.
I clearly recall a situation in one company I worked for, when a developer got lambasted by a manager for having failed to achieve the work output he had been assigned (yeah, let's ignore the awfulness of that for a moment). I recall him coming back to his desk, thoroughly p****d off, muttering to himself 'Doesn't that a***h**e realise I spent all of yesterday trying to fix a CICS problem that we had'. If there had been the appropriate spirit of cooperation and collaboration in that situation, and if the developer had been able to put forward that CICS-fixing activity as a backlog item, then maybe everyone would have been aware of the work necessary to fix it, which clearly delayed the completion of the other work.
Maybe this is a good reason to have 'Technical Stories'.
> To: firstname.lastname@example.org
> From: ronjeffries@...
> Date: Tue, 1 Feb 2011 10:30:19 -0500
> Subject: Re: [scrumdevelopment] Re: Scheduling Defect Fixes
> Hello, Roy.
> You really do not want to go down the Technical Stories rathole.
> Here's why:
> 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 126.96.36.199.
> 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 require
> > effort to be expended), we can still give an updated estimate of
> > completion time, or features that can be completed by the stated
> > deadline.
> Actually, we cannot. The reason is that working this way, we do not
> 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, sometimes
> > wildly, over time).
> I don't know that. If the completion time or number of features
> 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
> be removed.
> Ron Jeffries
> Hope is not a strategy. -- Michael Henos
> 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:
> <*> Your email settings:
> Individual Email | Traditional
> <*> To change settings online go to:
> (Yahoo! ID required)
> <*> To change settings via email:
> <*> To unsubscribe from this group, send an email to:
> <*> Your use of Yahoo! Groups is subject to:
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.