Re: [scrumdevelopment] Re: Backlog of technical tasks?
- I believe the crux of the issue is that it can be hard to justify technical stories in terms of business value. If you can't make that justification, you can't prioritize it as part of the backlog.E.g. Why does the customer want/need me to refactor xyz() into class J?We all know the technical debt needs to be worked down, so some are saying just put it on the side and handle it as overhead via slack.On a healthy team, we handled as much debt as we could with each story as the story touched it.On a not yet healthy team, we are putting them on the sprint directly, because in fact it's easier to justify the customer value when you're having issues..rob.
- --- In firstname.lastname@example.org, "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