Tips for Writing Technical Stories – By Carl Fitches

This time 10 years ago my role as a BA was centered around changes, enhancements even overhauls of front end, user facing web journeys. Taking our customers from point A to achieve some value at point B. I won’t say it was easy every time, but certainly writing the industry standard user story in the format “As I, want, So that….”, made complete sense.
When I then made the move to Compare the Market over 4 years ago and joined the Home team looking after the Home Insurance journey the regular front end changes made very direct and tangible changes to the value customer’s got out of our site. Making user stories with our “As I, want, So that” templates we had at the time, easier to complete.
Compare the Market encourage staff to move around so I took up the opportunity to join the Data Team as their Business Analyst. Then more recently I moved again to work on the Rewards team i.e. the code behind what sends you your Meerkat toy or fulfills Meerkat Movies membership. What was different was that these teams provided a lot of back end services, perhaps services to other teams or to augment other services. I found that the users of these services were often much further removed than that I had been used to. Often therefore I found the team and myself as a BA could struggle write stories per the “As I, want, So that…” template.
A classic symptom that this is happening is when teams write stories that begin with “As a developer…” or “as a system….”
An entire backlog filled with stories like this can easily become unwieldy. Over the course of time, the team have no context of what they are building and most notably, how it is going to be used eventually from an end user or customer perspective.
If the above sounds familiar to you I have used some techniques to make the task of writing a technical story a little easier. Below are some of these techniques that I hope you may get some benefit from. I’m not going to dictate which one is best to use as each one has its pros and cons depending on your situation.
Don’t Feel You Have to Force the User Story Format
Imagine a scenario where some reference data is currently not being backed up. Let’s assume that it is being used on the front end however the existing functionality satisfies the needs of the user so making this change would lead to no enhancements to the user experience or work flows. We could of course, force a user story format, something like:
As a product owner, I want all data backed up so that everything can be fully recovered.
Whilst this story does describe the functionality required I don’t think it is as clear as simply writing:
We need to extend our back up scripts for our Mongo database as it currently is not backing up our reference data. Which would lead to data loss in a disaster situation.
The takeaway here is that if you and your team are struggling or spending too much time trying to squeeze a technical requirement into a ‘As I, I want, So that’ simply write it the best way you see fit and move on. The same thing could also be said for raising bugs.
Include Any Technical Work in the story
Rather than creating technical stories that sit alongside or as prerequisites to functional user stories, try to represent the technical requirement as a sub task within the functional user story itself. A top tip is if this technical work is a prerequisite to a number of functional stories then set that story as the highest priority and only include the technical work as part of that first, highest priority story.
One particular advantage of this method is that it ensures that the technical work is not ignored by the product owner.
Try the FDD approach
Wikipedia describes Feature-driven development (FDD) as an iterative and incremental software development process. It’s a methodology that has been around since 1997 but not talked about very much. The second main activity when using FDD is to produce a list of small functions called a feature list. These customer value functions are expressed in the form “action”, “result”, “object”. An example might look like:
Backup all data for online transactions
OR
Generate a unique key for a customer
Mapping is Key
I do however warn you to be careful with the FDD approach a non user story approach especially if your backlog starts to become overly saturated with them. One problem I have with FDD or any non-user centric approach is that it is missing the why. Meaning it becomes hard to prioritise them when viewing your backlog as the value they give isn’t entirely obvious. Where possible technical stories should be mapped to user stories so that it is clear how the functionality being developed relates to the value being generated.
I have often written the user stories in these situations at a really high level, even as an epic. The technical stories can then be mapped as children of this epic, and written in a way suitable for the technical team to work on.
Culled from Medium: Tips for Writing Technical Stories by Carl Fitches
We offer Business Consulting, Management Consulting, Lean-Agile Management Training services. Our business is in the UK, but we operate globally. We are unique because of our combined experiences and background in Law, Business Management, and IT consulting.
Join Our Enterprise-Scaled Agile Community