We've just launched plato for individuals

🔥

login


Google Sign inLinkedIn Sign in

Don't have an account? 

Tech Debt, Sprints, Bugs, and True Velocity

Agile / Scrum
Prioritization
Productivity

6 December, 2019

Matthew Tippett provides guidance on allocating time for tech debt during planned Sprint work in order to increase velocity and productivity.

Problem

Not all technical debt is bad but a team does have to be wise about incurring it. Accumulated debt can slow down velocity, decrease developer morale, or have everlasting effects on the entire business. Therefore, how an engineering leader chooses to deal with tech debt can make all the difference. Below are my recommendations on how to tackle this issue, specifically when one wants to focus on tuning velocity rather than trying to keep Sprints alive.

Actions taken

Don’t do story point estimates for bugs. Why? Because where do bugs primarily come from? Previous stories, previous stories that were marked as finished but weren’t completed. By estimating and discussing team velocity based on bugs you’re actually disincentivizing the submission of completed work. As a result, presenting a velocity that includes bugs in the story points is in fact displaying a flawed velocity. 

Do start with story points only for work that is adding value. Value could mean tech debt reduction - as in you’re reducing drag, investing in building a better system that makes developers faster, or accelerating the team and the process; or customer-facing functional improvements. By doing so, you will quickly observe what your true velocity is, your real forward momentum.

Don’t reward people for burning down bugs by including them in subsequent Sprints. It sets up a pattern and feeling of burning down tech debt when in fact that’s not the case. People are just completing work that they said was already done. I reward my team for how productive they are at solving business problems, and bugs aren’t business problems. Bugs are shortcuts that engineers took.

Do start carving out space for clearer exits from story points and discounting the fixing of bugs as progress. The team will begin to realize that they need to do better so that their velocity increases to the place where they think it should be. Only then can the team have effective discussions on how to balance tech debt versus nontech debt.

Do sell to engineers first the fact that bugs carried over from previous Sprints are not actually tech debt. Because ultimately they are the ones who control the knob on whether things get done or not. Furthermore, take a step back and talk about what the team’s true velocity should be and the forward momentum that should be happening.

Don’t expect that product managers will be immediately enthusiastic about adjusting to the true velocity. Say, for example, that your original velocity was 40 story points but your true velocity is only 20. You’ve now essentially made their product roadmap twice as long. Though now that the issue has been brought to the attention of the PM, something must be done about it. Together you can go through a root cause analysis, demonstrate the reasoning behind the modification, and communicate the plan to reduce tech debt and increase velocity. Explain that by doing so engineers will be more effective, increase the (actual) amount of story points per Sprint thus resulting in faster development.

Do establish how to minimize incoming tech debt by having a clear definition of what is means for something to be ‘completed’ and ensuring that engineers know exactly what needs to be done. Ultimately, this is driven by strong leadership as well as in the way that engineers do engineering. You need to find a healthy relationship between the work and the developers so that people understand what it is that needs to get done.

Do assess your Sprint capacity. Define your theoretical capacity. Then divide that into two parts: allocation for value added - which is either product stories or tech debt, and allocation for story points. But, it is imperative that you first have a true value of the forward work that you are doing. This allows you to have a better discussion about how much and where the lever between tech debt and nontech debt needs to be moved.

Lessons learned

  • Stop lying to your organization about your velocity. Stop saying that you work at a velocity of X when the forward velocity is really X divided by 2. Determine your true forward movement, decide what you can do to increase delivery velocity, and then adapt so that you can overcome drag and go faster.
  • There might be an initial shock and depression phase when you realize your real velocity. But this is your truth and thus your starting point. Take it to the team and send them the right message: that the misses from previous Sprints which were carried over as a form of technical debt are not to be celebrated as successful fixups. These should have already been done before.
  • It is crucial to involve developers in the discussion of tech debt, velocity, bugs, and story points. These are the individuals carrying out the work and consequently will be affected by any changes made. More so, it’s an opportunity for the team to take ownership and show their actual forward velocity of a Sprint as opposed to what has been declared as so in the past.

Related stories

Setting Guardrails and Containing an Increase in Cloud Costs
21 September

Michael Mac-Vicar, CTO at Wildlife Studios, dissects how to set guardrails that would contain the exponential increase in cloud costs.

Dev Processes
Productivity
Michael Mac-Vicar

Michael Mac-Vicar

CTO at Wildlife Studios

Don’t Let Yourself Be Held Hostage by Estimates
14 September

Marian Kamenistak, VP of Engineering at Mews, discusses how constant delays are usually caused by things other than inaccurate estimates.

Deadlines
Prioritization
Marian Kamenistak

Marian Kamenistak

VP of Engineering at Mews

Outcomes Before Outputs: Measuring Engineering Performance
14 September

Marian Kamenistak, VP of Engineering at Mews, explains why EMs shouldn’t be measuring the output of a team or individual engineers, but the outcome of the whole team.

Impact
Productivity
Marian Kamenistak

Marian Kamenistak

VP of Engineering at Mews

Get More Done by Working Less
14 September

David La France, VP of Engineering at Kenna Security, explains how managers can level up their skills and scale in their roles by learning to work less, but smarter.

Personal growth
Delegate
Impact
Productivity
David La France

David La France

VP Engineering at Synack

Architecture Council: An Idea for Advancing Organizational Strategic Orientation
28 August

Brad Henrickson, CTO at Scoop, shares how by establishing the Architecture Council he advanced strategic thinking of the engineering team and overall strategic orientation of his organization.

Impact
Productivity
Feedback
Brad Henrickson

Brad Henrickson

CTO at Scoop

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.