How to write a user story as a bunch of Devs with no (real) Product Owner input
It’s something every developer has had to deal with at some point:
“Our backlog is getting a bit sparse in detailed stories. What’s next to focus on?”
“Oh, that important next feature, that’s the new thing we care about”
“OK great! What’s the requirements?”
“…We’re still not 100% sure of the middle, but we want the end to do something like this.”
It can be a real minefield if you have a Product Owner (person who determines what it is the application / component / product should do) and they either don’t have a full grasp of what is required by the end users of the application, or aren’t engaged enough. Sometimes there’s legitimate reasons behind this, and most of the time it falls to a “I don’t have the time to prioritise this role enough, I’ve got other things to do”. (This is perfectly reasonable when most POs I’ve worked with in the past have had the role added onto their workload, rather than having room made in their responsibilities to commit to the role).
So you’re left in a position I have regularly found myself in (and I’m sure I’m not alone) of the application builders needing to draw up the designs, with only a vague idea of what can or should be done to accomplish the vague end goal.
If your team is practising Agile (or some form of it) then chances are you need to create these designs with enough of an idea to have a finger in the air guess at the complexity (note: not time) involved in delivering the requirements in question.
How as developers can we navigate this minefield without ending up with a story that makes no sense, has no value and ends up being more of a hindrance than a help? I’ve listed out a few top tips that I try and follow when I’m writing out any user story in the absence of a product owners input.
What’s essential?
As a set of developers it’s really easy to miss the wood for the trees. We can (I know I do) get bogged down in the detail, the minutiae, of the story and what we want the task to achieve (should the button be 8px away from the border or 12? Meanwhile we’ve not asked the question of ‘Do we even need the button’.)
When you write a story, I try and think of a single, digestible sentence, that captures what the story needs to accomplish. There are a lot of frameworks to use. “As an X, I want to Y, so I can Z” is a popular one, but it can sometimes still be a bit too much to cram in (and particularly Z sometimes feels self-evident)
“We want to give the user a way to contact the help desk”
At the moment we have no idea on absolute specifics, because the PO is not available. But we have managed to capture the essence of the story. From there we can start to build. We can frame this essence a bit more professionally:
“As a user, I want to be able to contact the help desk through my application”
Some assumptions are OK!
In my experience product owners are happy to let developers and UX run with an idea a lot more than developers (in particular) think they are. If you create something that lets the PO do what they asked for initially, they’re generally quite happy. Why then, do developers fall into the trap of wanting to check every minute detail with a PO? (Full disclosure: this is definitely something I suffer from).
Obviously it would be great to have a full time UX team designing things for you as you need them with full specs that you can just build (one can dream) but usually this isn’t the case, and some of the gaps need filling by the developers. The best thing to do is to do what feels the most sensible.
What has been done in the application before to make sure that the new story feels like it fits inside the application? Have you used forms to submit information before? Have you already got a means to send emails in the application? These questions can help you frame the essence in the correct detail to move forward.
“As a user I want to be able to contact the help desk through my application
- An icon needs adding to the side bar that allows us to access ‘contact’.
- This should take us to a form that allows us to submit a question”
We now have the essence of the story, and a framework of what we can do.
Make it measurable
The best stories I’ve experienced have been ones that were contained, concise, and had a definitive completion. How do you know if you’ve completed a story? Usually you have acceptance criteria, which is great, but only if those criteria can be definitively complete (or still definitively incomplete.)
Add unit tests to improve our coverage
How can we possibly estimate how complex the story is with acceptance criteria that are hard to determine and impossible to agree on definitive completion. If I add a single unit test to a codebase of a few thousand lines and my coverage goes from 60.3% to 60.4% is that enough? Probably not, but how can we know?
Add unit tests to improve our coverage of the state management system so it covers over 80% of all lines.
Much more definitive, measurable, and helpful.
In our help desk example:
“As a user I want to be able to contact the help desk through my application
- An icon needs adding to the side bar that allows us to access ‘contact’.
- This should take us to a form that allows us to submit a question
- Our acceptance criteria is that on submission, help desk gets an email with the body containing the question.”
Less is more — write it for any developer
One of the easiest pitfalls I believe developers fall into (Again, full disclosure: I always catch myself doing this) is over-engineering the story. I think this is because most software writers look at the problem and go “how would I solve this problem”. This is perfectly reasonable when estimating a story that’s written but when writing the story, you have to take a bit of caution to make sure you don’t write the acceptance criteria and story details in a way that over-constrains the story, and hinders the creativity of your colleagues.
“As a user I want to be able to contact the help desk through my application
- An icon needs adding to the side bar that allows us to access ‘contact’.
- This should take us to a form that allows us to submit a question.
- The form should consist of a textarea to insert your username, a box to submit a replying email address, and underneath that a bigger text area to add your question. Underneath should be two buttons, one to submit and one to clear
- The information should be stored in the state in a new section, and submitting should get the information and send it to a new endpoint, under api/help/contact.
- We should include at least the mail icon and the explanatory text should be positioned above the form stating what the form is for: “Please fill this form in to get in touch with our help desk, we will endeavour to reply as quickly as we can.”
- The components should be separated and stored in their own sub directory in ‘./shared’
- Our acceptance criteria is that on submission, help desk gets an email with the body containing the question”
While it may seem that the story has been filled out with more detail, the acceptance criteria hasn’t changed. The details have become bogged down with implementation and suddenly the developer that picks this task up has no scope to experiment, explore and discover the best solution to the problem. Instead they have to simply ‘complete by numbers’. From experience, this type of story isn’t a fun one to complete. The sense of accomplishment is lost, and in extreme cases it can feel a bit like hand holding.
Celebrate the differences!
Developers are complex creatures. We need sunlight, water, caffeine, and stimulation. We also solve problems and approach issues from completely different perspectives. We are not product owners. We can pretend to be them, and some developers (not myself) have a knack for swapping those hats effortlessly, but we are not a one size fits all profession. And that’s a good thing! It means we can combine in multiplicative ways, rather than just adding more of the same to the mix.
To make sure we’re combining and working in the best way we can, we need to add less, rather than more, to the definition of our user stories (in the absence of a recognised product owner).
Less is more!
