2932RE: Re: [scrumdevelopment] Re: What to do with "loose ends"
- Mar 9, 2004
>> Yes, but is it not true that these low priority "loose ends" tendto stay in the "Product Backlog" forever?
>> That was what I understood to be the original question.MF> There's another possibility. You could just drop them after a few
MF> sprints by convention. I can understand that being contentious
MF> has its advantages. If an idea is really worthwhile, it will come
MF> again, and perhaps with enough passion and interest that next time
MF> it to become part of a sprint. If it never comes up again, it
MF> probably means that it was a fluke.
Absolutely, drop the stuff that clearly won't make it into a sprint in
the foreseeable future. In addition to the reasons Michael mentions,
it gets to be a big administrative burden to carry around an
ever-increasing backlog. And as the system grows and evolves, and
people's understanding grows, a lot of the backlog items would need to
be re-written anyway to make sense, even if they did become high
enough priority to make it into a sprint.
If you find yourself adding a lot of items to a backlog, and then
dumping them later as low priority, you'd be better off trying to
filter out more of those low priority items up front. There is a
natural tendency to want to capture every little idea and
nice-to-have - one of my current duties as product owner is to make
sure people concentrate on the core stuff, reassuring them that we'll
be in a much better position to understand and assess the importance
of the other stuff later in the project. I know that if the product
backlog gets too large, we will be just as likely to forget stuff
because we lose sight of it in a massive backlog as we would be to
forget it because it isn't there in the first place. This is a hard
nut for some people to swallow (and a good indication if they are
really getting into an agile mindset).
Getting back to the original problem Dennis raised, the goal is to
avoid having those little cleanup items in the first place. When
customers or testers are working closely with developers, most of
those little problems will get cleaned up
before the end-of-sprint demo. If the software really doesn't look
ready for prime time, a customer or tester will be more likely to say
"no, it isn't ready yet! Better fix it before showing it in the demo."
I've found it is obvious in a demo whether developers have been
working on their own, or have been getting good feedback from someone
with more of a business / end-user focus.
- << Previous post in topic Next post in topic >>