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

Are We Solving the “Right Problems”?
13 November

Michael Vanhoutte, Chief Architect at Aprimo, discusses why it is important to establish that a problem you are trying to solve is the right one and how the engineering obsession with ‘fixing the problems’ can lead us astray.

Impact
Productivity
Prioritization
Michael Vanhoutte

Michael Vanhoutte

Chief Architect at Aprimo

From a Dysfunctional Group to a High Performing Team
28 October

Narbeh Mirzaei, Associate Director of Engineering at HelloFresh, recalls how he transformed a dysfunctional group of siloed individuals into a high performing team.

Team processes
Productivity
High Performers
Narbeh Mirzaei

Narbeh Mirzaei

Associate Director of Engineering at HelloFresh

Why AB Testing Is Good for Your Company Culture
28 October

Graham McNicoll, CEO of Growth Book and former VP of Product and Engineering at Education.com, recalls how he introduced data-driven decision-making and AB testing to drive growth, and the unexpected effects it had on development speed, team alignment, intellectual humility, and collaboration.

Team processes
Managing Expectations
Agile / Scrum
Collaboration
Graham McNicoll

Graham McNicoll

VP Product and Engineering at Education.com

Introducing Processes for Continuous Improvement
30 September

Peter Berg, Founder and CTO at Forward, recounts how he introduced processes for continuous improvement and thus creating a more psychologically safe working environment.

Impact
Productivity
Coaching / Training / Mentorship
Peter Berg

Peter Berg

Founder / CTO at Forward

The Quick Fix to a Slow Team: A Consultant’s Perspective
30 September

Peter Berg, Founder and CTO at Forward, describes how he helped ramp up a slow-moving team by applying his simple, yet expert approach.

Team processes
Delegate
Productivity
Agile / Scrum
Peter Berg

Peter Berg

Founder / CTO at Forward

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.