Ensuring value in technical user stories…

“Technical” products are increasingly growing as concepts like Machine Learning, Data Science and Deep Learning become more popular and effective to solve problems. As Product Consultants we ensure the products we are delivering provide value to our users, but how do we ensure technical stories on the product backlog are delivering value to the users and understood by the whole team?

Anyone who asks me this question will get my unhelpful response of “there is no such thing as a technical story”. A user story is a simple description of a feature told from the perspective of the user who needs it including what they want and why they want it, meaning everything on our backlog should provide value to the user.

A step-by-step guide to writing technical user stories:

Step 1: Start with the value statement

Including the value statement in user stories allows us to think about the user, the user’s needs, and the problem we are solving.

As a {user who needs the requirement}
I want to {what the user needs}
So that {what the user is trying to achieve}

It is important to avoid using integrating systems or technical development teams as the users (e.g., As a Solution Architect). Instead focus on the actual end-user and the value brought to them, if you are not able to articulate the user value of the story it does not belong on your backlog.

Instead of this:

As a developer, I want person names and date of births to be extracted from case documents,
So that I can clash the entities against external data sources

Do this:

As a member of the fraud intelligence team,
I want a person's name and date of birth to be extracted from case documents,
So that they can be used to identify links and detect where a person may be involved in multiple fraud cases

Step 2: Acceptance Criteria

Acceptance criteria are used to clearly define the scope of a story. Avoid using any technical jargon or solutionising in the acceptance criteria. Personally, I find writing acceptance criteria in plain English the most effective and even more so for technical requirements, this ensures the whole team can understand the story, are aligned on the outcome, and that it can easily be tested. 

Example:

• Person names are extracted from pdf case documents
• Person date of births are extracted from pdf case documents
• Person names are extracted from word case documents
• Person date of births are extracted from word case documents
• Extracted names and date of births are stored combined
• Extracted combined entities are de-duplicated per case document

Step 3: Technical notes

We can’t capture everything needed for implementation using value-based statements, I like to add a “technical notes” sub-section. Technical notes are used to record any technical architecture diagrams, definitions, dependencies, decisions, or approaches discussed during the team refinement session for a specific user story.

Step 4: Use sub-tasks

Another method to ensure that technical thinking is documented is the use of sub-tasks, allowing the team to divide the user story into lower-level technical tasks.

This provides the lower level of detail that technical colleagues require but also ensures the higher-level user story is understood by the whole team and delivering value to the end-user.

Step 5: Follow the INVEST acronym

The INVEST acronym is essentially a checklist to ensure a user story is a “good user story”.

If the story fails one of the criteria the team should not bring the story into sprint or split the story, otherwise they are at risk of not delivering.

Features should always be split into consumable user stories that meet the INVEST principle. Stories should be sliced vertically rather than horizontally, this allows the team to focus on end-to-end user value.

Step 6: Backlog review

Stories should be continually reviewed by the team following Steps 1 – 5. Reviewing the stories on a regular basis with the team will create a shared understanding across the team, allow for collaboration on the best approaches, create a sense of ownership and ensure the story is fully understood across all team members.

Summary

Ultimately there is no difference between a technical story and a user story, they both should aim to provide value to the end users. User stories should contain at a very minimum the value statement and acceptance criteria describing the type of user, what they want and why they want it.

Asking “why”, working closely with your technical team and following the steps above you will ensure that your stories are delivering value to the end-users and that stories are understood by the whole team and stakeholders.