5 effective ways to instantly write better agile requirements
Every development team needs requirements to know what to build. Well written requirements are great — obviously. They bring clarity. They shorten feedback loops. And make teams more effective. But even the best teams struggle to write them from time to time.
How do you get better at it?
There are many ways. And it’s more art than science. To help with that, the agile scene has come up with a series of practices. Here I have distilled some of my favourites, from the mainstream to the exoteric (but still useful!).
User stories
I bet you heard this one before. User stories are a format, a template, to help you write your requirements in terms of user value. You write them in the first person like this:
As a <role> I want <goal> so that <value>
As a <student> I want to <borrow a book> so that <I can prepare for my exams>
That’s the classic format. It’s very user focused. But on certain occasions other formats might work better depending on what your focus is:
Outcome-focused: In order to <achieve something> as a <role> I want <value>
Scenario-focused: Given <context> when <event> then <outcomes>
The scenario-focused style is also great to define user stories’ acceptance criteria. These are short sentences added to the user story that define when it’s done.
What about technical work such as upgrading a library? Those often have no direct user value. In such cases it’s fine if your team decides to ditch the user story format. But my recommendation would be at least capturing a “Why?” for the story. That will help the person doing the work not to get side-tracked.
The rest of the article is full funky of acronyms.
INVEST in good user stories
INVEST is a mnemonic to what good user stories look like:
(I)ndependent — the story can be released by itself
(N)egotiable — stories can be improved in conversation with the business
(V)aluable — your user will be able to do something they care when you deliver the story
(E)stimatable — there is enough detail for the team to gauge the story size
(S)mall — you want to aim for stories that can be ideally completed in a day, but never beyond a sprint. That makes it easier to track progress and the story can be released sooner for quicker feedback
(T)estable — testers will be able to assess when the story is done (ideally with automation)
Itsy-bitsy SPIDR
You want your stories to be small. But often it’s hard to do. So, the SPIDR acronym will remind you where to slash things:
(S)pike — don’t have enough information to re-write a large story as smaller ones? Run a short investigation (e.g. a day) called a “spike”
(P)aths — draw a flow chart for user story, then break it down around different paths
(I)nterfaces — go for a minimal UI first or split around interfaces (e.g. browser, OS)
(D)ata — start with the most common type of data, then add new stories to build on that
(R)ules — consider relaxing business rules first, then add more rules through new stories
Just remember — each of your smaller stories should still follow the INVEST principle.
The 3 Amigos and the 3Cs
The 3 amigos are the Business, Developers, and Testers.
You bring the amigos together to write stories. Why? Because each one will bring a different perspective. The Business will define the problem. Developers will come up with solutions. And Testers will keep everyone real verifying the solution.
And the 3Cs is one way you can run that session.
It’s an acronym for Card, Conversation, Confirmation. The Business will bring in the high-level stories descriptions to the session — say one liners. And everyone will have a Conversation and write the fine details together. The Confirmation bit is defining the acceptance tests that assess when the story is done.
The author of the 3Cs proposed a new order of the Cs in 2019 (link). He now thinks it should start with a Conversation, followed by a Confirmation (writing the details), followed by a Card. That sounds better!
Lastly, it’s desirable to bring all team members to these sessions. Just keep an eye on team dynamics. You want everyone to make a contribution. And in larger teams that might be difficult. When that’s the case you can do a first pass with a subset of the team, and only then involve everyone for a refinement.
Elephant Carpaccio
You still remember you want your stories to be thin vertical slices. Like a cake. You do not want to write stories per layer (e.g. DB, backend, UI). That will create dependency nightmares and deliver no user value. What you want is a slice of the cake. A thin slice of the cake that is!
It takes practice to get it right.
That’s why two agile guys created the Elephant Carpaccio workshop (link). It’s a description of a short session where teams will be able to practice and learn breaking stories down. It takes 90–120 min and it revolves around writing stories and coding (!) a retail calculator. Anyone in the team can take the lead and facilitate this workshop.
Writing the perfect requirements
Unfortunately, that’s impossible. Sorry to disappoint you. But you can get better at it. With time, practice, and a bit of patience, you will improve. And in the process you will help making your team more effective.
You might also find useful:
Want to connect? LinkedIn
