On a mailing list I’m on there was a thread recently about dealing with technical debt in a scrum team.  One of the responses went something along these lines (paraphrasing a bit here)

For delivering functionality you should use stories, but for technical debt don’t.  All teams accumulate technical debt and dealing with it doesn’t fit into the story paradigm so just create tasks in your sprints to deal with it that way instead.

This, of course, garnered a response from yours truly as follows (with a little editing):

-----

Why doesn’t it fit into stories?  All “non-functionals” can be represented as stories with business value.  If you can’t do that, then they shouldn’t be done.

Examples:

  • As a Dev Manager I want the XYZ module refactored so that future development continues or improves upon the pace it is at now
  • As a Team Lead I want to clean up the FxCop warnings and reduce the cyclomatic complexity of the XXX assembly so that it is easier to change when we need to deliver the functionality expected in later sprints.
  • As an Architect I want to improve some of the implementations the team has made so that it aligns with the SOLID principles and provides a system that is more adaptable to changes in requirements
  • As a developer I want to clean up the rubbish I wrote in the previous sprint so that I can make the code easy for others to understand when they look at it

All of these can have a business value attached to them, be prioritised by your product owner, and broken down into tasks by the team, just as they should be.  I’ve seen too many teams putting lipstick on their pigs and failing to deliver simply because “technical purity” was deemed more important than delivery (and I’ve definitely seen the reverse as well!).  Every team carries technical debt – heck, code is technical debt all by itself – but the level of that debt that should be managed and balanced against new functionality by the product owner in consultation with the team, not by the team on their own.

-----

The lesson? Technical debt is a business risk.  Avoid accumulating it whenever and wherever practical.  Prevent it through sound development and architectural practices and improve and adhere to your Definition of Done. Once it’s there though, it’s up to the product owner and not the team to decide how much effort should be put into reducing the debt versus delivering new functionality.

Teams that mutiny against their Product Owners and do what they deem appropriate have either failed to convey the cost of debt sufficiently or have failed to understand the business drivers that drive the Product Owner to prioritise new functionality over of a sustainable code base and have ineffectual Scrum Masters that are not managing the process correctly.  If this is you and your organisation, it’s time to end it and put things right.