4

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?

  • 1
    how can you fail a sprint? If you mean "not completing all the work assigned to it" then my only comment can be that the sprint failed the team. Time to drop such ideas and start being agile! – gbjbaanb May 22 '15 at 12:22
  • 2
    @stuperuser: There are (at least) two ways to look at sprint points: as a committment, or as a projection of what you think can be accomplished. Since agile is not just about completing work, but completing it at a sustainable pace, calling it a commitment (which implies the team will work extra hours if necessary to make the commitment) isn't in the spirit of agile. Agile is more about planning than promising. – Bryan Oakley May 22 '15 at 13:13
  • 1
    Related question (not a duplicate): Should technical debt be scheduled as a feature or a chore (or a bug)? – user22815 May 22 '15 at 13:29
  • 1
    @BryanOakley or maybe we can just say Scrum (with its pigs and chickens, sigh) isn't really agile :) – gbjbaanb May 22 '15 at 14:25
  • 1
    I've found that the business folks are happier when the dev team commits to sprint-work, even if it means regularly agreeing to less work than we think we can do. That also means we tend to have several days of "free" time, which we can reserve for technical debt, experimentation, learning ... or pulling in a few more stories to impress the business folks. – svidgen May 22 '15 at 14:53
7

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.

2

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.

1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.