Stop 08 · Systems & Technical UnderstandingTopics · 7/9

Understanding Technical Debt

In short

Ever wondered why a 'tiny change' takes the team two weeks? Often it's technical debt: past shortcuts the team now has to work around. BAs who understand it make fairer plans.

Shortcuts taken to ship faster now that cost more to maintain or extend later — a BA benefits from understanding this concept to have informed conversations about why 'just add one small feature' isn't always simple.

The purple blob looks at a wall switchboard covered in tape with a tangle of extension cords hanging below.

Think of it like this

The hostel room switchboard

The switch broke, so someone taped it. Then an extension cord for the kettle. Then another one plugged into that for a heater. Each fix was quick. Now adding a lamp means untangling everything first, and one wrong tug trips the whole floor.

Watch it happen

Features shipped per sprint as debt piles up

1/5A new team ships about 10 small features each sprint. Code is clean and easy to change.

The big ideas

What you need to know

Like a loan

A shortcut borrows time now. Interest is paid later as slower, riskier changes until the debt is fixed.

Not always bad

Taking on debt to hit a real deadline can be a smart choice, if it's tracked and repaid.

Make it visible

Debt items belong in the backlog with a business reason, so the PO can prioritise them.

Translate it

'Refactor billing' means little to stakeholders. 'Cuts billing bugs and speeds up GST changes' gets a yes.

Save yourself the pain

Common mistakes

Oops

Pushing every sprint to be 100% new features.

Do this instead

Support the team reserving some capacity for debt, so delivery stays steady over time.

Oops

Dismissing 'it's tech debt' as an excuse.

Do this instead

Ask what the debt is, what it costs and what fixing it would allow. Then help make the business case.

Your mission

Spot debt in real life

~15 min

Quick check

A team skipped automated tests to launch on time. What's the most likely long-term effect?

Go deeper

1Ask an engineer to walk you through a real example of technical debt they're managing.
2Learn to frame technical debt paydown in terms of future velocity, for non-technical stakeholders.
3Understand why a rushed requirement can directly contribute to technical debt down the line.