Agile Zone is brought to you in partnership with:

Steve Smith is an Agile consultant and Continuous Delivery specialist at Always Agile Consulting Ltd. An XP / Lean developer with 10+ years of experience in enterprise software development in Britain and New Zealand, Steve favours practices such as Pair Programming and Test-Driven Development to build quality into software products. As an early adopter of Continuous Delivery he has overseen transformation programmes in multiple organisations to reduce lead times and increase product revenues. Steve is a co-author of the Continuous Delivery and DevOps book "Build Quality In", a co-organiser of the monthly London Continuous Delivery meetup group, a co-organiser of the annual PIPELINE conference, and a regular speaker at conferences such as Agile On The Beach and QCon New York. Steve blogs at Always Agile Consulting and is on Twitter at @AgileSteveSmith. Steve is a DZone MVB and is not an employee of DZone and has posted 29 posts at DZone. You can read more from them at their website. View Full User Profile

Treat Technical Stories as User Stories

  • submit to reddit
Technical stories with demonstrable business value are rare, but can and should be prioritized 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.

Published at DZone with permission of Steve Smith, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)