Technical Debt and Scrum

January 27, 2014

Scrum is in no small part about owning development tasks as a team, not as individuals.  How often in our careers have we called development tasks "done" simply because we’ve finished coding and testing them?  How many times have we reported a feature was "done", knowing there were really one or two more things we knew needed to be completed in order to deploy it?  How many times have we called a feature "done" when in fact we knew it still needed to be documented?

Would our customers have also considered this feature to be "done"? Was this feature production-ready?

The truth is, we never intentionally set out to mislead anyone, especially our customers.  Instead, as developers, testers, business analysts, stakeholders, and managers – we simply have differing opinions of what “done” means.

One of the beautiful things Scrum forces a team to do is to explicitly define, up front, what "done" means.  Another beautiful thing Scrum says is that no single developer, tester, business analyst, or otherwise owns any single task in the sprint backlog.  Instead, the team owns every task, and it's not "done" until it meets the agreed-upon definition of "done".  Typically, this means that the task is code complete, meets defined coding standards, has been formally tested, is documented to the extent that it meets your customer's expectations, and is ready to deploy with no additional effort required to make it deployable.  Regardless, anything that is included in the team's definition of "done" that isn't complete is simply referred to as technical debt.  It's a debt because it's an activity that takes time to accomplish.

This leads us directly to the reason why Scrum emphasizes the importance of having cross-functional development teams.  The more team members operate in individual silos, the more technical debt is likely to be incurred.  Conversely, if team members are cross-functional then they are able to "swarm" a task until it meets the definition of "done".  Often times this means a developer will assist in the QA process, or will personally write documentation as opposed to relying on a dedicated technical writer.

I recently took a Professional Scrum Master class from Don McGreal at Improving Enterprises, and he said something on this topic that I thought really cut to the chase:

I'm paraphrasing here, but he said "If a development team says they can complete eight items from the product backlog in a sprint, then when confronted with the agreed-upon definition of "done" they backpedal and say they can only complete five...  That is a good indicator that this team is regularly incurring technical debt."

Even if you aren't using Scrum, I think it's always wise to make sure your teams (including customer) agree upon a single definition of "done".  It makes technical debt more visible, and greatly improves their chances of delivering on time while exceeding customer expectations.

Information and material in our blog posts are provided "as is" with no warranties either expressed or implied. Each post is an individual expression of our Sparkies. Should you identify any such content that is harmful, malicious, sensitive or unnecessary, please contact marketing@sparkhound.com.

Meet Sparkhound

Review our capabilities and services, meet the leadership team, see our valued partnerships, and read about the hardware we've earned.

Learn How We Work

See how our Plan/Build/Run methodology drives real client success, and gain our team's perspectives on timely tech topics.

Engage With Us

Get in touch any of our offices, or checkout our open career positions and consider joining Sparkhound's dynamic team.