Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Tech debt doesn't have a direct business value until the improvements are seen against other stories being delivered quicker. Achieving or failing sprints affects morale and delivery in the long run too, so if necessary tech debt causes sprints to fail or velocity to drop.
While it's going to be different for each organisation, is velocity a measure for the team or for the business and is "pure" tech debt with no business impact expected to be measured in a team's velocity?
Velocity is defined as "number of units of work completed in a certain interval". To implement a unit of work, you typically have an existing part of software and add some new code and/or change some existing code. When the existing part of software contains a lot of technical debt, and you have to deal with it to implement a change, one would expect to need more time to complete a unit of work. On the other hand, the creation of new technical debt happens often in expectation to need less time to complete a unit of work in the current sprint.
So what is measured here depends always on the team and the actual code base (and probably the whole organization around it). There is nothing like an absolute "velocity of the team".
However, if your question is if there should be units of work dealing only with the removal of technical debt, and if they should be counted the same way as units-of-work for business requirements, then it should be obvious that mixing those two things up might give you a wrong picture about your team's real development speed. In fact, you have to decide for yourself if you want to measure how fast your team works, or how fast your team can deliver new business value. To my experience, most customers prefer to pay for the business value they get.
One way of looking at velocity is to think of it as "the amount of work that can be completed in a given amount of time". Assuming that fixing technical debt is actual work, it should be counted.
You must remember that velocity is just a tool to help you work better. If adding technical debt to you velocity helps you, do it. If it doesn't, don't. The only reason to track velocity s to help you plan better. If you ignore work that you actually do, that doesn't help IMHO.
I would say not to count technical debt in your velocity. However, as a developer, unlike an inexperienced manager, you know that ding this means you could get arbitrarily more or less work done depending on how much debt you add or remove that week. So take that into account during your planning.
If your software is in a bad state, requiring two days a week of handling technical debt for the next year, or if you have messy developers creating debt at a massive rate, then take that into account and your velocity goes down as it should in the situation.
