Technical stories, a miscast artifact of agile development

Technical stories are a controversial topic in the agile world. If you google technical stories antipattern, you’ll get plenty of people advocating never to do them. On the other hand, some teams religiously outsource any refactoring onto technical stories.

Should we eschew technical stories altogether? Or should we embrace them and put all of our (technological) dreams and hopes into them?

I believe this kind of story belongs in a healthy backlog, as long as we don’t use it to hide our corpses under the rug.

What is a technical story, anyways?

I’ll quote myself for this since there isn’t a universal definition.

A technical story is one where the main stakeholders are the developers in the team.

The end-user benefits only indirectly from such a story. As our system becomes better, the theory goes, we’ll have an easier time delivering actual user stories.

Are technical stories an antipattern?

Back to the original question. To answer it, let’s picture a user story as an iceberg.