Tips and tricks for writing User Stories: how to avoid rookie mistakes and why the “Best before” date is important
Author: Josip Osrecki
Your organization decided to go the “agile” way and wants to make sure the end-user is in focus (rather than blindly following the specification). Every employee needs to think about this – from sales agents to the operations team deploying to production. So from now on, you will use user stories (US) instead of requirements. But what does that exactly mean – what principles are important to a user story and how does it differ from a requirement?
Although it sounds easy to write it in a standard “AS A… I WANT… SO THAT…” format I have found that the majority of newly formed teams struggle with implementing it correctly. Here are several most common mistakes organizations make.
When it is the right time to write a User Story?
One of the most overlooked (and easy to make) mistakes is to try to write a user story from existing functional/marketing/technical specifications. People often ignore the fact that a user story is so lightweight for a good reason. And that reason is to share it with everyone in the product’s value stream as soon as possible. You want to validate your assumptions and ask for feedback to make sure your idea is feasible. Writing detailed requirements and only then transferring them to the US format will most certainly mean the development team(s) will validate the assumptions too late. This will lead to a painful User Story ping-pong with the person who wrote the initial requirements and a lot of wasted time writing spec you decide not to use. Sounds familiar?
Sharing User Stories on time will cut feedback time on the “business” side of your organization.
We will then split my user story to the technical US, the test US the dev US so that everyone would have their own Story…
Even with experienced teams that know that a User Story should be vertically sliced, it often happens that somebody suggested writing a “technical” story. And after a couple of sprints teams quickly regress to writing a US for each role (test, dev, analysis, integration…) and you end up with silos within the team. If a US (or an Epic) is too large, ask the team what is the simplest thing every member can do to estimate if their part of the US is as easy (or as difficult) to implement as they initially estimated. If this is the team’s first touch with the agile approach, it is sometimes more difficult to think more about the “Check and Act” part of the PDCA cycle and less about “everything needs to be implemented”.
This will cut feedback time on the implementation side.
But we need much more information and the User Story format is not enough…
I completely agree. What you want to do is to make sure you create and share the appropriate amount of information at the appropriate time in the US – and product – lifecycle. In practice, this means that the initial US will have 1 sentence and 5 Acceptance Criteria. After receiving feedback, it would grow to 10 Acceptance Criteria and a couple of rough workflow sketches. Later on, somebody would attach some kind of lightweight specification to it. Keep in mind, though, that the US core should still be lightweight and understood by everyone.
What if the US or part of it is rejected or it turns out it holds little value? Well, that’s great – it means it saved you tons of work hours to write detailed specifications before validating it. You can use this time to focus on those User Stories that do have value and that can be implemented.
This approach will help you keep waste in your process to a minimum.
In conclusion, alongside making sure that implementation of your US provides some value to the customer and to keep the feedback loop short – your US should have “Best before” (or “best shared before”) date.
Photo by Austin Distel on Unsplash
