Re: [scrumdevelopment] Re: Backlog of technical tasks?
- On Thu, May 1, 2008 at 5:22 PM, Kane Mar <kane_sfo@...> wrote:
> I would suggest that a better approach would be for the team to reduceSprint Planning Meeting:
> technical debt by
> leaving all legacy code in better condition than they found it. Over time
> they will improve
> those parts of the system subject to the most change. Not only that, by
> doing this they
> don't ask the PO to choose between quality and functionality. There is no
> question of the
> PO "forbidding" the team from doing what it takes to reduce the technical
> debt. Just my
PO: How much would this backlog item cost?
Team: 5 units
PO: 5??? Why so much
Team: we need to fix some technical debt, write unit tests, refactor
PO: What if you don't do the latter, and just get the story done?
Team: well, we really need to address all these issues. We've put
them off for months, and really recommend fixing things as we go along
PO: I understand, but we need to release and we need all the
features, and right now they add up to too many points for the Team's
velocity. If you hold off on reducing the technical debt, how many
points is it?
Team: well, maybe 3. But we really need to do this work.
PO: I've heard your concern. I want you to hold off on that.
ScrumMaster: OK, I'll put down 3 points.
Happens all the time.
- --- In email@example.com, "Jeppe N. Madsen" <jeppe@...> wrote:
> I've been skeptical about putting technical tasks on the backlog forYes, and there's really no contradiction between these
> many of the same reasons listed in this thread. I think we should
> make "the world a better place" one step at a time, by refactoring the
> code as it's touched due to new requirements.
approaches once we see the Sprint Planning Meeting
as a good faith negotiation.
Normal technical debt should be paid off through
the definition of "done" for product feature stories.
Things like this might include refactoring away
duplicate code, complex conditional logic, long
modules, nested "catch" blocks, poorly named
methods and classes, normal database schema
changes, normal upgrades to third-party
> If there really are technical debt that hindersYes, when progress on multiple fronts is impeded
> progress, this is an impediment.
by severe fundamental underlying debt issues
(often at the infrastructure level, like platform
changes, major database changes, major library
changes) it may be useful for the team to make
it visible in the product backlog as a step toward
breaking the repayment work into manageable
pieces. Anyone can add items to the Product
Of course we still expect some feature delivery