How to Capture and Manage Technical Debt in Agile Development

If you're concerned about the technical debt accumulated by your organization, then consider developing ways to capture and measure it.



In my last post, I suggest teams should target nimble architectures and leverage agile principles that enable iterating on the design. Don't plan to get it perfect, plan to get it wrong, iterate on what you learn, and recognize when the business is impacted by architecture limitations.

Here's one approach agile teams can use to capture technical debt during their planning and commitment process.

Capturing technical debt during commitment


Some teams will finalize stories, estimate them and commit to them at the start of the sprint. Others put in more formal agile planning processes that aid in developing deeper backlogs and more descriptive roadmaps. Either way, most agile teams are collecting the following basic information on the stories they commit to:

  • It's rank/priority relative to other stories
  • It's size/estimate, often in story points
  • It's connection to a bigger picture through epics and releases
  • It's connection to code if they've integrated agile and version control tools

My suggestion is to ask and capture some additional data points at time of commitment 

  1. Will this story correct any existing technical debt
  2. Is this story intentionally adding to our technical debt

The reason to ask this at the start of the sprint is that it gives leaders a couple of options

  • Should you increase the priority of stories that address technical debt? [Maybe]
  • Should you intentionally increase the story points for stories where you know it will introduce technical debt [YES!]

My answers are in []. In case you were wondering, THIS IS NOT GAMING THE SYSTEM! Make these governing rules and decisions transparent. Where you are addressing technical debt, it may be a reason to prioritize the story above other requests of similar business value. That's why it's a maybe. But if it's introducing technical technical debt then I strongly recommend increasing the story points. You're adding complexity, and story points should represent both effort and complexity of the implementation

Updating technical debt at the agile demo


The second opportunity to discuss technical debt is at the demo. In addition to formally capturing it, doing this at the demo will remind business stakeholders of its existence and importance.

For each story demoed, ask the lead developer if any new technical debt was introduced. Ideally, this will have already been captured in the backlog as a story tub, but if this was missed, a colleague can look to capture.

By discussing it openly, there's a greater chance that business and technical leaders will look to address technical debt in a future sprint. If not, consider these recommendations on how to get an agile product owner to pay for technical debt.


No comments:

Post a Comment

Comments on this blog are moderated and we do not accept comments that have links to other websites.

Share