Our team is starting to refine a set of stories that cover components and UI as part of an upgrade to a newer version of Angular. These components will then be used to recreate screens in an existing application. We are considering this work technical debt.

Is there a recommended format for writing technical debt stories?

We use the "As a ... I need to ...so I can ...", as well as Gherkin's "Given > When > Then" acceptance criteria, for our standard stories that are more directly customer focused.

Is there something similar that should be used for these tech debt stories? Or should we just list technical requirements?

  • 1
    Do you have a set of user stories that capture the application that are you upgrading and converting? If so, are these user stories still valid? – Thomas Owens Feb 8 at 13:31
  • 5
    Technical debt is a developer concern, as such it needs to be phrased in a way that makes the case that it is truly debt, and that debt is hurting the product in some way. Particularly if it is something that has to be done before you can start working to enable new features. Beyond that, there's no recommended format. – Berin Loritsch Feb 8 at 13:34
  • @Thomas Owens - Good point. The more I think about it, I believe the set-up of the new version of the app, which has been completed, would've been technical debt, but perhaps the development of these components should be handled in standard user stories. – Bheitzer Feb 8 at 14:17
  • @Berin Loritsch - Thanks for helping clarify this in my mind. This particular statement set me straight: "Particularly if it is something that has to be done before you can start working to enable new features." – Bheitzer Feb 8 at 14:27

"Scrum Framework only describes what needs to be done, but does not enforce how it needs to be done." "User Stories are a great technique for capturing functional requirements in a ‘good enough for now’-manner that leaves room for further conversation. But Scrum doesn’t prescribe nor require them. Other techniques are fine, as long as they help promote three things:

  1. They make the Product Backlog understandable to the Scrum Team and its stakeholders. A stakeholder should be able to view the Product Backlog and have a good sense of what's coming up and in what order;
  2. The level of detail they demand should fit the uncertainty of product development. Items that lie further into the future should require less detail than items that are about to be pulled into a Sprint;
  3. They should foster an ongoing communication and conversation between the Scrum Team and stakeholders (which includes users);"

Both quotes from "Myth 4: In Scrum, the Product Backlog has to consist out of User Stories" on Scrum.org

You also may like to watch "Telling Better Stories" keynote by David Evans.


  • Backlog can have all kind of stories. In my teams I suggested three types: user, technical, research
  • You don't have to use ‘As a [role] I want to [action] so that [reason]’ format for a user story.

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.