Sprint Planning - Eliminate Technical Debt

Sprint Planning - Eliminate Technical Debt

Definition

As a software project manager or product owner, the term ”technical debt” may not ring a bell. Over the last several years managing Agile teams, I have come to realize that lurking technical debt introduces risk and represents unplanned work that impacts schedules and ultimately the long-term health of projects. I believe that project managers and product owners should make technical debt a priority and factor a “re-payment” program into project schedules as a regular part of planning.  Over the course of a project, it is tempting for an organization to become lax regarding software quality. This may be for a number of reasons: the primary ones being that the team is expected to complete too much functionality in the given time; or quality is not considered a high priority characteristic of the software.

How it Accrues

There are a few different reasons that come to mind:

• QA is not brought in early enough in the sprint. Usually because they are shared resources.
• Too many stories are being worked on at once

How to Avoid It

Addressing the two point above:

• QA is not brought in early enough in the sprint:
   - I prefer to have a dedicated QA resource in each team
   - When QAs are brought in late they cannot approve all stories in time
   - The QAs need to be side-by-side with developers from the start.
     Working together the QA and developers can establish testing early
• Too many stories are being worked on at once:
   - If all stories are worked on simultaneously then they will all hit QA at the same time
   - I recommend tiering your Sprint Backlog into 3 tiers, 3 equal divisions
     The top tier is worked on first. Developers cannot take stories from tier 2
     until tier 1 is done or approval is granted by the Product Owner
     When a tier is done it goes to QA as each story is completed.
     Then next tier is started.
• If "Task Inflation" is causing technical debt then the PO needs to work with the business unit in order to break down the stories as smaller units

Visit Agile, LLC Today