3

As we are implementing some stories we find some things which need to be put on a backlog as technical debt, often because there are larger questions linked to other stories or features which cannot be trivially answered and would derail our sprint goals. We might be bashing out a first version and want to make sure we record things so we can manage and record our technical debt activity.

WI types such as requirements and issues had seemed like good options to keep these clearly segregated but Azure DevOps seemingly only allows you to see the following work-item types in your backlog:

  • epic
  • feature
  • story
  • bug
  • task

I don't really like the idea of a story "xxx technical debt" and putting them as tasks on the actice story doesn't match our process - we want to mark the story complete but record debt (or other design questions) for a later iteration. And typically these are not really stories, since implementing them makes zero difference to functionality or users.

Would adding as bugs make sense perhaps? Is there a suggested direction from MS or a widely used pattern that's close to being a defacto standard?

Improve this question
0

3 Answers 3

Reset to default
5

The point of a user story is to deliver value, cleaning up technical debt should be valuable (or it really wasn't tech debt). The want to have yet another item type really just opens up opportunity for people to start arguing if this is a story or an issue or a non-deployment item or any other type. Personally, I think having bugs as an item type is also a bad call, because people tend to overreact with bugs. Using bugs for tech debt will end up with many questions of why you have 30+ bugs in your backlog.

There are more things that deliver value than deploying newly implemented features. All of these things are still user stories. You may wish to classify them under different epics/features for reporting reasons, but that's about as far as you should go for different types.

Improve this answer
3
  • +1 for "There are more things that deliver value than deploying newly implemented features." Too many Devs I meet are focussed on [coding] the new stuff and [try to] ignore anything and everything else!
    – Phill W.
    Commented Nov 18, 2022 at 7:06
  • 1
    not just devs. Several times I've seen entire processes built around the assumption everything is code that goes to prod, and developers are essentially graded only on shipping code. Developers apparently never write implementation plans, documentation, prototype, research libraries to use, or prepare a knowledge transfers.
    – Ryathal
    Commented Nov 18, 2022 at 14:13
  • Definitely has to do with what devs are rewarded for. I find the average attention span of the present-day dev to also play a factor. In certain cases it can digress to be just a copy/paste race in a team -- find that perfect niche YT video/blog that shows exactly what to copy/paste for your problem before your colleagues do, just do it (don't reason as to the merits, approach, risks) & if it works, cool -- pat oon the back for you, on to the next one.
    – Alex Constantin
    Commented Aug 8, 2023 at 12:48
1

Out teams represent tech debt with the same story WI type, but use a clear label [Tech Debt] to call out that it's not a new Feature & also link it to a System Robustness-type feature. This allows to take stock of how much debt is accumulating & how much it takes away from working on new features.

To Doc Brown's answer, you can challenge the team to surface the User voice that would call for this technical debt work (if there really is one) e.g. "As a user, I want to just log in once & have the same UX across all your systems, so that I can make faster, easier use of all your offerings" . The exercise won't be as easy as for new features, but it should be valuable.

The Sprint Goal just communicates why the Sprint is valuable & tech debt work is fine to influence it as it is being set, considering again that there may be latent User voices that ask for system robustness, reliability or even feedback turnaround speed (if you're thinking of a WI like "Automate our test suite").

"[...] putting [tech debt] as tasks on the active story doesn't match our process - we want to mark the story complete but record debt for a later iteration" -- this is a Developer's decision, as they own Quality for the work being done. If you find that you predictably accumulate tech debt with each Sprint:

  • maybe there's too much pressure on new feature delivery, leading to too many quick & dirty solutions, just to appease management
  • maybe there's isn't enough effort being put into story refinement & Devs discover new complexity late in the Sprint, after estimates are already set
  • maybe your estimates do not account for the risk of more, hidden work / rework, but just face-value effort

There are a few angles you can approach this from.

Improve this answer
0

Any kind of issue tracker or backlog management system which is worth it's bucks will allow you to customize the related work item types.

For example, for Azure Devops, I found this here in the docs. That's probably better than shoehorning technical tasks into the predefined user-centric work item types.

Said that, I think the option of putting "technical debt issues" into the backlog should not be overused. Each "clean-up task" should finally have the goal to allow smoother feature development or easier bugfixing on follow-up tasks. If you cannot name the purpose of such a clean-up task from the point of view of a feature or user story, chances are high the clean-up will never happen. Most technical issues can be worked on during feature development or bug fixing following the "boy scout rule".

That does not mean you should never make use of a "tech-debt" work item, but use them sparely and with care.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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