User stories are great at capturing product functionality from the perspective of a user or customer: Each user story describes a piece of product functionality, for instance, “As an application provider, I want to register with the application centre so that I can use its services.” By focusing on a distinct area of functionality, the story allows the team to understand, implement and test the requirement. This strength is also a weakness: User stories are not well suited to describe the interactions between different features and to describe workflows.
To capture and explore the relationship between different stories, I have found it useful to complement user stories with lightweight models originally invented for use cases: context and activity diagrams. I also add important diagrams to the product backlog, as I explain in my post The Product Backlog Board.
Context Diagram with Epics
A context diagram that depicts user roles and epics, large and coarse-grained stories, is great to provide an overview of the product’s functionality. Let’s have a look at an example, a diagram that sketches an online application store called “Application Centre”:
The diagram above depicts three user roles: provider, user and administrator. It shows how the roles interact with epics that describe Application Centre functionality. It tells us, for instance, that the user and the administrator both review applications – to enable end user and staff ratings.
Note that the diagram does not list all epics contained in the product backlog, and it does not state all user roles. It rather focuses on the product backlog items relevant for a conversation between the product owner and the team, or the Scrum team and the stakeholders. This results in a diagram that is simple and easy to understand rather than complex and overwhelming.
Activity Diagram with Stories
To get a job done, users often carry out a sequence of steps and interact with different pieces of functionality. Activity diagrams are great at capturing sequences and workflows by connecting individual user stories. They also support the creation of complex test scenarios that go beyond single stories.
Let’s have a look at an example, a diagram that elaborates the epic “Register” on the context diagram above. It shows the key steps required for a user to register with the Application Centre:
The diagram above visualises the steps of the registration workflow by connecting three individual stories. It starts with stating the details of the provider company, continues with entering a user name and password, and if successful, accepting the usage terms and conditions.
User Story Modelling Tips
User stories modelling is a handy tool in the product owner’s toolbox. But like any tool, it wants to be applied properly. The following tips help you create great diagrams:
- Model collaboratively: User story modelling serves to create a shared understanding of the desired product functionality. Use them to capture the essence of a conversation, not to replace it! Create and update your diagrams collaboratively involving the team and as appropriate, the stakeholders.
- Focus: Apply modelling selectively and only describe relevant aspects. Focus on the relevant product backlog items and leave out the rest. Don’t include too much information or unnecessary details.
- Keep it simple: Keep your diagrams simple and easy to understand. Rather use additional diagrams to illustrate further aspects than cluttering a model with too much information. Complex diagrams are usually not helpful.
- Use simple tools: Use whiteboards and flipcharts with markers and pens rather than electronic tools. Simple, physical tools encourage participation and collaboration, and they avoid the illusion of perfection. You are likely to iterate over your diagrams, adapting them when they are no longer correct or removing them when they are no longer valuable.
Collaborative, lightweight and focussed user story modelling can help you create a shared understanding of the desired product functionality. Context and activity diagrams complement user stories and put them in a wider context. Any model related to user stories and epics should be the outcome of a conversation – and never replace it.