Making Tech Debt Visible
Julee Everett — April 11, 2018 — April 11, 2018
As a Product Owner, there is nothing more frustrating than having to use valuable development time to deal with technical debt. Like death and taxes, it’s just never a good time when those lurking defects decide to unravel.
We all know it is imperative to keep our products scalable and sustainable, but it is difficult to sell the idea of an upgrade or technical product time to stakeholders who are primarily focused on customer-facing features.
Persuade your stakeholders that time improving the product behind the scenes will increase productivity, sustainability, and scalability.
I’m going to pause a moment here to open up the definition of technical debt for this post. For the purposes of this post about making tech debt visible, we will not get into the strategies of solving for it.
Technical debt is defined, in this post, as “anything that impedes agility as a product matures.” Technical Debt certainly could be code-based, but it could also mean a lack of test automation and DevOps issues.
Technical debt is NOT undone work. Undone work, in contrast to technical debt, goes into the Product Backlog.
For more in-depth references, visit Frances Lash’s article on managing technical debt or the valuable series on this topic on Scrum.org . In short, no matter your definition, we can all agree, technical debt is a measurable risk, and must be mitigated.
Read on here to find out how to connect with stakeholders in a more influential way and show the impact that technical debt is causing.
USE IMAGES
Data tells a compelling story, but helping stakeholders visualize data in meaningful ways creates an impact that trumps any speech, email or table. My favorite technique is this four-step solution introduced to me by Professional Scrum Trainer Ryan Ripley:
1) Start with a standard sprint burn-down with an ideal line. It’s not an official element of Scrum, but it can be a valuable technique for the Development Team to visualize progress towards the Sprint Goal. If you are not using an agile tool that creates this chart for you, this can be modeled in Excel.
2) Be diligent about tracking daily progress. This is the development team entering true remaining effort on each task, not time spent, to show progress of the work against the sprint timebox – this is your true productivity line. I compare this to the value of measuring the remaining runway if you were a pilot landing a plane… no-one cares about the runway behind you! The burn-down can help visually show the empirical process of accountability, inspection, and transparency — the real differentiators in Scrum.
3) Track all technical debt in the same estimation model you are using on your team (break fixes, refactoring, defects.) It doesn’t matter if this is points or hours, they just need to be consistent. You can label items in your tool, but you may just want to do this manually.
4) In the last step, you will use your sprint burn-down as a base, and simply add the time spent on the technical debt on top of the product development work, as shown below. This will visibly show how much productivity is lost to break-fixes, defects, and outages and other technical debt.
When the impact of defects and technical debt (waste), is made transparent, we create an opportunity for the Scrum Team to inspect their quality practices. Adaptations that reduce technical debt and prevent defects can ultimately lower the total cost of ownership of the product. That is music to a Product Owner’s ears.
For tips on managing tech and making technical debt visible, review Ian Mitchell’s post on Scrum.org about using a technical register.
TEACHABLE MOMENTS
Never underestimate the power of the Sprint Review. This is a formal feedback loop in Scrum to engage stakeholders on a strategic level. Data is good, but stories are better. Speak to your business partners in their language by translating that lost work from time to dollars to show the impact from a budget perspective. The Sprint Review can be a powerful coaching opportunity for the team, the Product Owner, and stakeholders.
Let us know if these tips help your team become more proactive about reducing tech debt. What else have you used?
Co-written by Julee Everett and Ryan Ripley
Hone your craft, Speak your truth, Show your thanks
Business & Finance Articles on Business 2 Community
(27)
