Re: [scrumdevelopment] Re: Scheduling Defect Fixes
- Hello, Roy. On Tuesday, February 1, 2011, at 11:07:38 AM, you
> Ron, as you well know, iterative, agile, XP etc. methods allIt turns out not to be the case that it applies to other 'user
> 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.
requested requirements'. While new user requirements can pop up at
any time, surprise requirements tend to cluster toward the beginning
of the project, because that is the time of greatest learning.
Similarly, technical issues tend to cluster toward the beginning and
middle of the project, again because it is the time of greatest
learning. There are two primary exceptions. Performance issues often
crop up late. Redesign issues driven by newly discovered defects
often crop up late.
Defects, on the other hand, tend to crop up toward the end of the
project, I think mostly because of generally inadequate testing.
Thus their impact as an unknown element is disproportionately bad,
the closer we get to our desired ship date.
In addition, every new user requested requirement is carried to
term, if not conceived, in the mind of and purview of the Product
Owner. Her job is to listen to what users say and decide what to do.
On the contrary, defects are not in her mind and purview, and are
essentially out of her control. As you like to say, "they happen".
As I like to say, programmers put them in without being asked to do
The cases are quite different. And therein lies one of the forces
that pushes against defect stories.
>Yes, it can reflect dysfunction, and unfortunately it happens very
> 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.
frequently. However, even with the best teams and teamwork,
prioritizing technical vs user usually comes down to trust, because
there really is no consistent way to monetize features and technical
changes on the same scale. So the problem of technical stories is
serious /whether or not/ we have good teamwork.
Thus the recommendation to avoid technical stories.
>Yes. I do not care to revisit the DBMS issue. But I agree that
> 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.
technical matters might pop up, and some of them are surely due to
not being fully prepared.
Nonetheless, most of these changes can be undertaken incrementally
and as part of doing user stories. When that is possible, it is my
opinion that it should be done. When it is not possible, we would
schedule those activities /as if/ they were user stories, and, in my
opinion, we would /not/ track them as if they were feature progress
on the burn charts.
It is legal to track them. It is recommended by some other advisors.
What is clear, however, is that if you are going to track them as
progress, you must also advance the goal line every time you accept
one as a backlog item. I just prefer not to advance the goal line,
and not to track them, because it keeps us focused on the
high-leverage material, namely true features.
> So what is this 'overhead' that you suggest we track, and how isBug fixes are overhead, by my definition. I make this definition to
> it factored in to the teams activities? ... which will presumably
> affect the future delivery dates or achieveable functionality.
help keep that laser focus on not creating bugs. If you can't get
credit for fixing them, I hope you will be less inclined to put them
Activities not directed to the project at all are overhead, such as
all-company meetings, assignment to other projects and any other
such activity. Other overhead items show up in every project. If
people start noticing time wasted, track it.
I would track the time simply. If we were scheduling defects and
purely technical work in the Sprint, I'd just keep track of the time
on those cards separately. If there was significant time away from
the project, I'd get the team to track it. I would display this
information on a regular basis on a simple swim-lane chart.
> I clearly recall a situation in one company I worked for, when aInstead, it appears that either the manager has amnesia, or the
> 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.
developer worked on something he was not asked by the manager to
work on. I can see how this would be a serious problem. I do not see
how the *ssh*l* was supposed to know, if he didn't ask for the CICS
work and the developer didn't tell him. Most of us who can read
minds choose not to reveal that power to civilians.
I would agree that some rather terrible communications problem arose
between the developer and the manager. Apparently the developer
worked on something the manager did not assign. In Scrum, that would
mean someone was working on something the PO did not assign. That
would be, in my opinion, very bad. No one can manage a situation
where people are not working on the things they are supposed to be
working on ... nor where people are working on the right things and
no one knows it.
> Maybe this is a good reason to have 'Technical Stories'.It's a good reason to have managers and Product Owners actually
directing the work. It's a good reason to have all the work on the
backlog. It's a good reason never to undertake work that isn't on
the backlog and scheduled by the Product Owner. Scrum addresses the
manager / developer communications concern directly, out of the box.
It might be a good reason to make this thing a "technical story", or
it might not.
It is a bad plan that admits of no modifications. -- Publius Syrus (ca. 42 BCE)
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.