This post explains how to write user stories at the right level of detail, and how to derive small, ready stories from big, coarse-grained epics.
One of the things I love about user stories is their flexibility. A user story can be big, medium-sized, or small. This allows us to sketch a product with big stories, and then progressively add more detail and refine them into smaller user stories, as we learn more about how to meet the user needs.
But this flexibility comes at a price: I often see user stories that are too small or too big, that contain too much or not enough information. Deriving the right stories, and getting the level of detail right can be challenging.
This post suggests a simple, yet effective solution: distinguishing between two types of user stories, epics and ready stories, and deriving the ready stories with the help of a shared sprint goal or hypothesis.
Epics are big, coarse-grained user stories. An epic sketches a feature or bigger piece of functionality. It acts as a placeholder for more detailed stories. Think of the epos Odyssey. It’s a collection of stories about the adventures of Ulysses including meeting the Sirens, and defeating a Cyclops.
Epics allow you to sketch the product functionality without committing to the details. This is particularly helpful for new products or major product updates, as it buys you time to learn more about the users and how to best meet their needs. It also reduces the time and effort required to integrate new insights: If you have lots of detailed stories, then it’s often tricky to relate the feedback you receive to the right stories, and it can be a big effort to change them without introducing inconsistencies. Let’s have a look at a sample epic:
The epic above tells us that the persona John wants to register for an event. The details of the event and the registration are left open for now. Similarly, the acceptance criteria – captured on the right card – are sketchy too. The details will emerge, as we learn more about the event registration by developing software and exposing it to the right people.
Ready stories are small, detailed stories that can be implemented. These stories have to be clear, feasible, and testable: Everyone should have a shared understanding of the story’s meaning; the story should not too big or complex; and there has to be an effective way to determine if the functionality works as expected.
A ready story should also take into account additional aspects: the user interface design and the operational qualities that are specific to the story. Examples of the latter are performance or interoperability. I prefer to work with a paper-based design sketch to capture the user interface, and constraint story cards to describe the qualities, as the following picture shows.
The ready story above is much more specific and detailed than the sample epic discussed earlier: The details enable the development team to implement and test the story successfully.
From Epics to Ready Stories
So far we’ve simplified things by distinguishing between epics and ready stories. But we haven’t discussed yet how ready stories are derived from epics. My solution is to identify a sprint goal or hypothesis for the next iteration before the ready stories are written, as the following picture illustrates:
Step 1: Write the Epics
Let me show you how this process can be applied using my Product Canvas tool. The canvas is essentially a multi-dimensional backlog that allows you to describe your product holistically.
The Product Canvas supports working with epics and ready stories by providing dictated sections. It also offers the context for finding the right epics: The user journeys – scenarios, workflows, or storyboards – are a great hunting ground for epics. The epics are placed on the “Epics” section, as the following picture illustrates.
Step 2: Select the Goal of the Next Sprint
Once the epics sketching the product’s main functionality have been written, I populate the design and constraints sections on the canvas. Then I select the goal of the next sprint – either to address the most critical risk and/or to deliver functionality to the stakeholders including the users. Examples of a sprint goal are: “Validate our central user interface design ideas”, or “Be able to release epic B”. The sprint goal is placed at the top of the Ready Stories section, as the following picture shows.
I find it very beneficial to involve the entire team, the product owner and the development team, in selecting and formulating the sprint goal. This leverages the team’s collective knowledge, and ensures that the goal is shared. The latter ensures that the entire team is moving towards one goal. This encourages teamwork, and it makes it easier to analyse the feedback.
Step 3: Derive the Ready Stories
After selecting the sprint goal, I determine which epics contribute to the sprint goal, for instance, epic A and C on the canvas above. I then derive small stories from the appropriate epics, and I order the new stories depending on their importance to reach the sprint goal, as the picture below illustrates.
Finally, I ensure that each story is ready and has the necessary sketches and constraints attached. The entire teams should carry out this step to ensure that the stories are clear, feasible, and testable. The right amount of ready stories are then pulled into the sprint and implemented.
Step 4: Update the Canvas and Repeat the Process
After exposing the outcome of the iteration to the right people, the insights gained from analysing the feedback are worked into the canvas: Existing epics are adjusted or removed, new epics may be added. Then the next cycle starts. A new goal is selected, and new ready stories are written.
Post a Comment or Ask a Question
Hi Roman, this is a very insightful article, still relevant 7 years since the date you posted it judging by how recent the comments are.
I have a question about iterations.
We create an epic to cover specific features or user experience. e.g.: I want to be reminded to do X on a daily basis. We then come up with a solution, which we split into user stories. We release live, collect feedback, and then carry on iterating to improve the original problem we are trying to address.
1. If we keep the same epic and add new stories, the epic never gets delivered and always has new stories added to it.
2. The alternative is to create a new epic with a “version number” (e.g.: I want to be reminded to do X on a daily basis V6)
I think none of the solutions above really work, we should try being more creative about naming each new iteration. if the solution is different (ability to set up auto-reminder vs highlighted new content in the app each day, for instance, we create a separate epic with a name specific to the solution we are implementing). If the changes required for a new iteration are simple enough and don’t really qualify for a new epic, we have user stories added to the product backlog but with no epic attached to them.
Would love to hear your thoughts on this.
Thank you for sharing your feedback and question. I recommend working with themes in addition to epics. I use a theme to describe a larger feature or capability like notification. You can think of a theme as a category or “chapter”. This allows you to progressively break down epics into user stories until they are done while still being able to add new notification stories.
Does this help?
We have been struggling with the timing of these events, which we call grooming sessions. Previously I had an elusive expectation that a single grooming session would turn epics into ready stories. A couple of symptoms that this was too ambitious:
– a (introvert) team blanking out on the epics
– a (extravert) team enthusiastically creating ready stories, only to come back to them at planning time, with a whole new mindset and design
– hastily designed stories, which turn out hard to implement, spanning multiple sprints
Three possible answers
1) give the team time to prepare the session (for introverts)
2) deliberately have two sessions (for extraverts)
3) have a ready story not as a result of a grooming session but as a result of a sprint itself
Which one do you favor? Do you have other alternatives?
Thank you for your comment Dieter. Please have a look at my articles “Creating Effective Sprint Goals” and “When Should Product Backlog Grooming Take Place?“, which should answer your question. If that’s not the case, then please let me know!
I found this article very interesting. I wonder if you could share a more practical example of how it would all come together. In your view, is an epic a higher level goal (perhaps linked to an element of the roadmap, with an approx timeline) which would then be divided further into sprint goals (which would then broken into smaller stories?).
Thank you for your feedback. I like to distinhuish between product capabilities or features, epics, and user stories. I include capabilities and features on a product roadmap, but not epcis. Please take a look at my article The Product Roadmap and the Product Backlog for more information.
Hope this helps!
Hi Roman, great site and love the clarity in explaining the concepts.
Can you please tell me if there is a naming or numbering convention between the epics and the related ready stories? Every sprint will pool ready stories from various epics, i was wondering how do we keep track of epic completion across multiple sprints?
Thanks for your feedback, Anup. I am not aware of any general nemonic convention. I suggest that you rework your epics and ask the dev team to estimate the remaining effort as they are partially implemented. Hope this helps.
Wise use of epics and story decomposition is very helpful for providing context and vision for the team, along with the necessary detail of “ready stories”.
It’s tricky, though. I see two common mistakes people make with epics and decomposition.
1. Folks like Dean Leffingwell favor epics like “Video Streaming”, which to me don’t really capture what problem we’re solving for the user. It seems to me that epics should capture the goals and perspective of the user.
2. More commonly, story decomposition usually occurs along functional lines.
I wrote a blog entry with a fictional “epic conversation” to illustrate the common mistakes with stories and epics and how to deal with them.
The main opportunity that agile practitioners seem to miss when it comes to story splitting is dividing epics or stories into versions that iteratively strengthen the acceptance criteria. I’d love to get your thoughts on this idea, Roman.
Hi Roger, Thanks for your comment. I derive epics from the goals of the personas, and I use them to sketch the overall product functionality. I prefer to decompose epics just in time based on the sprint goal / hypothesis by breaking out detailed stories required to reach the goal. This minimises the upfront story writing effort, and it makes it easier to update the Product Canvas / backlog. Epics, of course, capture only the product functionality. For more complex interactions, I like to work with scenarios, storyboards, and workflow diagrams: https://www.romanpichler.com/blog/agile-scenarios-and-storyboards/ I find it helpful to appreciate that there are different ways to capture product ideas and requirements. I recommend choosing the techniques that work best for the product being developed.
It seems to me that Ready Stories are normal User Stories (I.e., ready to be developed) which were already distinct from Epics. Am I misunderstanding something?
Hi Jason, A user story is simply a brief narrative that describes how a user or customer is likely to use the product. A story may or may not be ready for development. I’ve written more about the desirable qualities of a ready story here:
Does this help?