Treat Technical Stories as User Stories

Technical stories with demonstrable business value are rare, but can and should be prioritised with user stories

Ron Jeffries has continued his work on technical stories in a new article stating that we don’t need technical stories on an agile project. His well-considered  argument is as follows:

  • Technical stories have a different value proposition to user stories (improved velocity in the future vs. improved business value)
  • Therefore, it is difficult to prioritise a user story versus a technical story
  • Therefore, it is wasteful to present technical stories to the Product Owner for prioritisation

Ron proposes that rather than using technical stories to improve testing practices or the existing software design, “testing and design improvement are inherently part of the work of doing stories” and therefore the proper solution is to “make the code a bit better every time we pass through it“. I agree 100% with this – from experience, the only effective way to improve codebase quality is a bit at a time, and to fix Broken Windows – but for me, the challenging questions are what is a technical story?

A technical story is an item of work in the Software Debt Backlog that pays off a chunk of debt that is understandable and valuable to the Product Owner

The above definition means that the vast majority of problematic technical stories should be correctly classified as technical tasks – work to fix Broken Windows that can and should be accomplished within the context of a user story, as mandated by Ron. A technical story should only be applicable in the exceptional circumstance of a well-defined set of technical tasks being identified that will pay off a noticeable piece of Software Debt, in turn providing some business value.

“Use aspects to decouple security code and caching” is not a technical story. “Upgrade web server to achieve company SLA” is.

Tags: