Adding Debt to your Daily Scrum

Debt in a project (technical or otherwise) is something no one wants in a project.  But I believe it belongs in every Daily Scrum / Stand-up meeting.

Everyone who uses Agile/Scrum knows the the three big questions used in a Daily Scrum or Stand-up meeting:

These questions are meant to be the daily pulse of the project. Among other things, this short meeting is how you (as project leader or Scrum master) spot the trouble spots before they become crises.

But a few years ago I noticed — after being stung by it a few times — that there was a question missing. So I’ve added a fourth question that everyone is expected to answer in daily Standups:

I added this to our meetings after noticing that sometimes a task would be called “finished,” would be moved to testing and then acceptance — only to find out later that, in order to make the original time assessment and get the task (and user story/feature) into the current Sprint, someone had to cut corners: some temporary art was used, a bit of unfinished design was papered over, or a single-use function was quickly created, knowing that it would have to be refactored later.

Ideally when this happens, a new task should be added to the backlog to be addressed later — that would keep the debt transparent. But in my experience this often does not happen, whether due to the intense focus in mid-Sprint or the reluctance of someone to point out that their task isn’t really finished.

So, I started including the debt question to be answered by everyone every day. It takes only a moment to answer, so it’s not in danger of burdening the brevity of the meeting. It’s also not always the most comfortable question to answer — no one likes to admit that they had to take a shortcut that’s going to need attention later. But it also gives team members a natural outlet that’s just part of the process to bring this up. Doing so gives everyone a more accurate picture of what actually remains to be done, and just as importantly, helps refine future task scheduling. Most of all, it prevents the dread of instabilities or unfinished bits lurking in the shadows as you come to a release.

Finally, having an open understanding of any debt incurred helps you as a manager spot those who are making a habit of cutting corners and help them to move past it. Left unaddressed, this practice can ultimately undermine the product, making it less robust or require a surprising amount of time in “bug fixing” (when a lot of debt is often silently taken care of). Helping those on your team estimate tasks more effectively, not cut corners — or do so judiciously and consciously — and ultimately make a better, more stable product is good for everyone. Even if it can cause a bit of squirming in a daily meeting.

[This originally appeared on Mike Sellers' blog.]