There are no “Technical stories”!

A prevailing anti-pattern in the industry is the use of “Technical stories” or work that cannot be defined as “functional”. Such work typically revolve around security, infrastructure, technical debt, migration activities, and anything that the team considers more technical than what the business can comprehend.

So, why is this a problem? One common complaint is that technical stories often don’t receive the same priority as business stories, resulting in delays that eventually reach a critical stage. And when that happens, it risks halting progress on all value-driven work for the business.

It’s not about technical work

If something is not understandable to the business, it cannot be prioritized fairly. It is unfair to expect Product owners to prioritize something they cannot see the value in or understand its benefits.

Its important to understand and illustrate the value of work in a common language that can help drive decisions.

Any unit of work improves the product for its consumers, either directly or indirectly, is valuable and can be quantified.

A model to think value of everything

I find FURPS+ as a useful reference to categorise the work.

• Enhances the product capability i.e. functionality (F)
• Improves the product usability i.e. User experience (U)
• Robustness of the system against failures i.e. Reliability against bugs, Availability against time to recovery (R)
• Address the performance i.e. scalability, memory management (P)
• And the internal quality of the product i.e. Supportability (S)
• Other considerations: Security, Observability and Tracebility, Ability to continuously integrate and deploy

However, what is important is being hyper-aware of the impact that technical work creates on the product and customer, and to state that explicitly.

Here are a few examples of why your current technical work can be viewed through a customer-centric lens.