Re: Backlog of technical tasks?
- --- In firstname.lastname@example.org, "Jim Schiel" <schiel@...> wrote:
> >on the
> > Bottom line -- technical debt is no different than anything else
> > backlog. Don't treat it like a second class citizen -- it's alwaysgoing to
> > be there and everyone should get used to it being there.Agreed... and now let me share more of the story that prompted the
When I implied a large technical debt, I was thinking of those
companies that had legacy code bases to deal with. One group I know
solved that problem of dealing with legacy debt by incorporating the
"payment plan" into the backlog. That is, because they had a large
technical debt with their legacy codebase, the team and PO agreed that
they would try to include a certain percentage of technical debt
stories in each sprint until debt was paid down below a certain
threshold and they made this team ground rule visible. So not only
did they make their commitment to the debt visible in the backlog, but
they also made the payment plan toward improved quality visible to
stakeholders by keeping the groundrules visible.
So I agree that technical debt should be balanced with other factors
the PO must consider and that balancing should be made visible through
the project backlog and the methods to prioritize the backlog.
- --- 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