The anatomy of a user story
I was recently asked how best to decompose problems or opportunities into “work”, and then how best to define and rally around each chunk of work as it’s designed, built, tested, shipped, and measured.
This is one of the most effective things you can do to accelerate the impact that a cross-functional team can have and, whilst I've written a little about the former, I somehow haven't written anything on the latter.
So, here goes.
Workings out
“But to what end?” you may well ask. Why break things down into smaller chunks? Why have central artefacts that define what each chunk entails? What is the goal?
For me, there are three distinct reasons:
- To enable teams to get working software in front of users sooner
Too much work in progress kills productivity. Breaking work into smaller pieces reduces this.
Doing so also gets you into the habit of shipping something regularly, and that repetition builds the collective muscle memory of the team.
- To minimise waste
At the highest level, visualing the scope of a problem or solution enables you to clearly and intentionally focus on the highest impact areas. Working in smaller deliverables enables you to course correct or, even better, pull the plug at the earliest possible point.
An advantage of creating a user story artefact is that it clearly outlines the desired outcome and, crucially, what is not required. That clarity on both sides trims off bags of ambiguity and uncertainty which could otherwise bog the team down and result in repeated conversations and unnecessarily tumbling down rabbit holes.
- To reduce cognitive load
Software development is an incredibly messy thing. There are many moving parts. Nobody can hold a whole problem and solution in their head, nor should we expect them to. You don’t need to document to the nth degree, but an artefact that outlines the high-level shape of a proposed problem/opportunity and likely solution, coupled with a bit more meat on the bones of each individual deliverable time and again proves invaluable.
I like the way Ant Murphy describes the concept of a "third reference point" being an accelerant to understanding and agreement - it’s exactly this principle in action.
To round this up, all three of these reasons support wider, overarching goals such as boosting team health and morale, improving external perceptions of a team, and making more of a positive impact on customer experience, ultimately in pursuit of one or more business goals.
It is, however, important to stress that these techniques are not mandatory. I’d encourage every new team to start here, and I believe every product engineering practitioner should learn how to do this if, for nothing else, to understand the thinking behind them. But they simply might not suit your team - especially mature, deep-rooted teams, highly collaborative teams. I've often found that these teams often cover all of these bases automatically with a much lighter touch.
Decomposition
I’d always recommend starting here. Even if you can’t or don’t want to create an artefact for each individual chunk of work, just the act of breaking something down into smaller pieces - especially if done collaboratively - can deliver incredible value. It can be the difference between delivering value in ten days rather than having to wait a hundred. It so often is the vehicle to whittle down scope and hone in on the kernel of a problem or opportunity where 80%+ of the impact actually lies.
No surprises that I’m going to hand off to my earlier story mapping article - start here if you’re new to the concept. If you want to get stuck in straight away, try our Miro story map template instead.
User story definition
There are many names for these. I call them user stories, or just stories. I’ve heard them called tickets, issues, tasks, work items, backlog items, product backlog items (PBIs), and product requirements definitions (PRDs).
Whatever you call them, at their core, they are just enough information to enable a cross-functional team to understand the purpose of this chunk of work, and then to go on and build, test, and release it.
Here's my starter-for-ten when I'm putting some shape around a piece of work:
| Element | Description | Example value |
|---|---|---|
| Title | A snappy sentence that describes the story. Ideally in verb-noun format if possible. | Update email address |
| Description | A concise, plain English summary of what we think we’ll deliver | This story covers adding in the ability to update email address in our web portal. |
| User story | Standard format user story to highlight who the core user(s) are, and why we’re looking to deliver this. There can be more than one. | As a customer I want to update my email address So that I receive any comms that are sent to me |
| Measuring impact | How will we measure the success of this feature? What impact are we hoping to have? | We hypothesise that this will reduce customer contact regarding email address updates by x, and increase marketing penetration by y. |
| Mock-up / designs | Ideally a flat or two showing what this will look like, a link to broader designs (e.g. Figma) and possibly a prototype. | Imagine a mock-up or two 🏞️ 🌆 and a URL 🌐 |
| Assumptions | Any assumptions that may need bottoming out before or during the engineering effort | Assumed that no validation is required other than presence of an @ sign - need to check |
| Dependencies | Anything that needs to be in place before this work can start, or before it can be released | Platform squad needs to release the API work before we can release this. Shouldn’t stop us starting it though |
| Out of scope | A bulleted list of anything that has been deemed out of scope, including anything that has already been delivered or is being delivered elsewhere |
- Ability to update email address in iOS app
- APIs to support this capability - they are being delivered by the platform squad |
| Release plan | Does this require a staggered release, or an A/B test? Are there any other considerations here? | Normal release. No need to stagger or A/B. |
| Acceptance criteria | Bulleted, plain English acceptance criteria. Should act as a checklist for engineers and QA, and be stepped through in planning / amigos. |
On launch of ‘Personal details’ page:
- ‘Email address’ field is enabled - ‘Update’ button visible and enabled alongside ‘Email address’ field On selection of ‘Update’ button: If validation fails: - Email address not updated - Appropriate error wording shown If validation succeeds: - Email address updated - Appropriate confirmation wording shown |
| Useful links | Any external resources that might help | An article about email validation we discussed in the shaping session |
| Additional notes | Anything else that might provide understanding | Worth checking what validation we have in place on the customer journey, and ensure we match up with that? |
Pro tips
- It is okay to stray from these templates. Don’t set hard and fast templates for your user stories (e.g. in Jira) with all these fields, and definitely don’t make them mandatory if you do. Just have a free text description field and have the above as headers by default, deleting as necessary.
- You don't need to be a purist about naming conventions for user stories. Verb-noun format is best, but it's okay to go with something different. Even something very solutiony is fine - whatever the most common terminology is for a thing.
- Document as you go. Use collaborative tools such as Miro or Confluence. Yes, it's good to come into a session with a straw-man story map or user story to get the conversation started, but get this up on screen (or the wall) and refer to it. Update it. Capture all of the good conversations that flow out of it.
- Share the load. I used to do a lot of this in isolation back when I was more of an "agile business analyst". This is okay, but you'll quickly make a bottleneck of yourself, and others in your team will either lose these skills, or never develop them.
- I still value the INVEST mnemonic. I do it subconsciously nowadays, and it doesn't always fit, but it's a good thing to bear in mind - particularly for people new to the concept of decomposing work into user stories.
- Minimise complexity within your user story artefacts (e.g. in Jira). Try and keep them simple - if they need to be put in a wider context, or have a boatload of tricky business logic that needs defining, do it elsewhere using tools like Miro, Figma, or Confluence. Go visual if you can - a flow diagram or a matrix can save you time and pain.
- If you have more than ten acceptance criteria, could you break it down into smaller chunks?
- User stories can and should change as they are delivered - heck, the N in INVEST stands for Negotiable. It's natural to try and lock down a "specification", but the nature of product development is that we discover as we go, and this should be encouraged and supported.
In summary
Breaking down work into well-defined user stories is a great way to enhance cross-functional team efficiency and achieve impactful results. This approach not only accelerates the delivery of software but also significantly reduces waste and cognitive load. By clearly outlining goals and constraints, user stories help teams focus on delivering value and maintaining clarity throughout the development process. While this method is particularly beneficial for newer teams, seasoned teams might find that they already incorporate these principles naturally.
