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

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

• 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.