When estimating (story points) a story that consists on extending a current functionality with a known tech-debt, should we consider the effort that will be spent to refactor the current code or should we estimate independently of this tech-debt?

  • 2
    Can you complete the task without refactoring? – Edward Strange May 21 '12 at 20:52
  • 1
    Yes, but we dont want to... – Marcelo Oliveira May 22 '12 at 19:12
  • Does refactoring add any business value? – Bryan Oakley May 23 '12 at 2:25
  • @BryanOakley - If it did then it shouldn't be tech debt. – SoylentGray May 23 '12 at 12:46
  • @Chad: I din't think that is always true. A weak architecture or poor implementation might mean that technical support is more costly than it could be. Even though fixing it adds business value, I would still classify it as tech debt. – Bryan Oakley May 23 '12 at 13:00

In agile if you can do it with out the change then you should not make the change as part of the story. So in that case you would not include the points for the tech debt.

You score the fastest way you can properly complete the story. If taking on the tech debt will speed up the story ie tech debt + story = less time than doing the story with out the tech debt then absolutely you should choose the route that includes the tech debt. But if the story is 3 with out tech debt but 5 with the tech debt then you choose the 3. You could still choose to go the route of clearing the tech debt but it will have an impact on your velocity.

  • I would change that to "fastest way you can properly complete the story". Agile isn't about fast, it's about providing business value, and being able to deliver what you promise (and being able to promise based on historical data). Delivering something fast that meets a strict story definition but adds technical debt isn't a goal of agile. – Bryan Oakley May 23 '12 at 2:27
  • @BryanOakley - Agreed. I tend to forget that not everyone sees the only valid paths to take are those that are actually valid. – SoylentGray May 23 '12 at 12:44
  • @chad, your answer does not consider how you're going to address the remaining technical debt in case you "can do it with out the change". – A Costa Nov 5 '15 at 11:26
  • @ACosta - Because this question is not about dealing with remaining tech debt. That is up to the business and the team how it will handle the tech debt that accrues. Typically management tries to ignore it until something happens that requires it be dealt with. Then it is a hair on fire emergency that must be done right now... you know exactly what agile tries to avoid in the first place. – SoylentGray Nov 5 '15 at 15:13

Your estimates should certainly take into account the technical debt. The point of estimating stories is to get an indication of how much effort it will take to accomplish something, and technical debt definitely contributes to that. In fact, you should take everything that might effect the time/effort it takes to implement a story in your estimates (for example, learning the business domain).

Sometimes, when there is a lot of refactoring work to be done, I've added a separate sub-task under a story, and estimated that accordingly. Otherwise, refactoring and dealing with technical debt is going to be a natural part of every story. It should be estimated accordingly.

  • So, you`re suggesting that it would be a good idea to take a look at the existing code when we are estimating a story? – Marcelo Oliveira May 22 '12 at 19:12
  • 1
    @MarceloOliveira yes, I think knowing the code-base will help you make better (more accurate) estimates. You probably won't have to do this every single sprint, for every single story, but it might help for the first few weeks of estimating. – Oleksi May 22 '12 at 19:18

Let's try both:

  1. Without Tech Debt: When work commences and you KNOW you'll have to refactor the code to make it work you'll probably decrease your velocity - since the overall complexity was underestimated
  2. With Tech Debt: You'll increase the 'story point' score since it'll link to the tech debt and "make that explicit" to everyone and could be factored into existing velocity calculations, so to speak.

So, what should you choose? I'd go for #2 since that makes explicit what the story entails, is more realistic a picture and exposes the 'hidden' jobs that may be lurking below (devils in the details, perhaps).

If you do go with #1 the team may be questioned for decreasing velocity and 'not bringing up the tech-debt fix' in the meeting. Just keep it clear - estimate with tech debt and your team will be happy (and so will the PM - a debt would be paid off since something valuable is preceded by it :)

  • So, the team should hide this information to avoid being questioned about velocity? We will decrease velocity due to this tech debt, thats a fact that must be visible to everyone. – Marcelo Oliveira May 22 '12 at 19:16
  • @MarceloOliveira - Sorry. I didn't want to imply that. My concern was that there is a 'risk' of it being hidden or 'implicit' and may be overlooked during 'project management'... – PhD May 23 '12 at 3:22

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.