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

How to Effectively Communicate on Slack
6 July

Shridharan Muthu, VP of Engineering at Zoosk, discusses effective communication using Slack including a recommended framework that entails three simple tips to make the most of the tool.

Internal Communication
Remote
Productivity
Shridharan Muthu

Shridharan Muthu

VP of Engineering, Backend Applications at Zoosk

Handling a Mistake - Adopting a New Workflow
6 July

Shridharan Muthu, VP of Engineering at Zoosk, describes how he quickly agreed to adopt new workflows, a mistake he later regretted, and how he handled the situation by spending the time to course correct and taking a stab at making things easier for his team.

Team processes
Agile / Scrum
Collaboration
Shridharan Muthu

Shridharan Muthu

VP of Engineering, Backend Applications at Zoosk

What We Learned From Running Open Spaces
30 June

Jeff Foster, Head of Product Engineering, highlights key learnings from his experience of running open spaces and if and how it contributed to an increase in innovation.

Company Culture
Productivity
Impact
Jeff Foster

Jeff Foster

Head of Product Engineering at Redgate

Some Ideas for Breaking Down Silos In Your Organization
30 June

Jeff Foster, Head of Product Engineering, shares how he managed to break down silos in his organization by encouraging their employees to choose their own team.

Team reaction
Managing Expectations
Company Culture
Internal Communication
Collaboration
Productivity
Reorganization
Jeff Foster

Jeff Foster

Head of Product Engineering at Redgate

Some Useful Tips for Decoupling Releases and Deployments
30 June

Pierre Bergamin, VP of Engineering at Assignar, outlines some useful tips for decoupling releases from deployment and increasing deployments by a huge factor, speeding up reverts and planning releases in a better way.

Agile / Scrum
Dev Processes
Pierre Bergamin

Pierre Bergamin

VP of Engineering at Assignar

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.