User Story Modelling

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 several 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 a single story.

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 context and activity diagrams 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 whiteboards and flip charts rather than electronic tools. Simple, physical tools encourage participation and collaboration. They avoid the impression of perfection and completion.

Summary

Collaborative user story modelling can help you create a shared understanding of the desired product functionality. Context and activity diagrams complement user stories, put them in a context and connect individual epics and stories. Any model related to user stories should be the outcome of a conversation–and never replace it.

Roman Pichler

Next The Release Planning Workshop »

Previous « The Product Vision Board

View Comments

Michael Ball-Marian says:

October 28, 2011 at 16:54

Great post Roman. I really appreciate your blog, and it is an area of Agile that doesn't get enough attention.

Much of the literature on Scrum and Agile is silent in regard to planning and understanding activity patterns (or use cases, etc.) Similarly, it is relatively silent about understanding and planning coherent user experience. Both of these exist "outside of" individual user stories, and consequently are often ignored by many fledgling agile teams. As a user-centered development shop doing agile, I know we struggled with this (and sometime still do).

Your blog and book have been useful to our teams in finding agile, lightweight ways to do this planning without falling back on "big up front" design. Thanks!
- Roman Pichler says:
  
  October 28, 2011 at 17:12
  
  Thank you Michael.
Arran Hartgroves says:

July 7, 2011 at 13:18

Thanks for the guidance, much appreciated.
Roman Pichler says:

June 24, 2011 at 09:06

Hi Arran, Thanks for the feedback.

I view a story as valuable if it is necessary to turn the product vision into a successful product.

I find that the features on the product vision board often end up as epics on the product backlog. I would suggest to create models only for those epics whose relationship with user roles or other epics needs to be explored further.
Arran Hartgroves says:

June 23, 2011 at 07:42

One more question!

Do you see a tie up between features on the Vision board and this epic model? Could a model be created for each feature?
Arran Hartgroves says:

June 22, 2011 at 19:55

Great post. I've been using use case diagrams with stories for a while just to organise and provide context.

Never considered the activity diagram approach but essentially are we not working with use cases, flows etc... (Nothing wrong with that btw, I'm just saying they seem to have converged - Use Cases are commonly perceived as non-agile). In the example above, you have a story "Enter user name and password", I've questioned whether this in it's own right has value (as part of INVEST) to the customer?
Mike Cohn says:

June 22, 2011 at 14:39

Hi Roman--
This is a nice approach that will be helpful on epics where we need a visualization to see how the parts fit together. Thanks for sharing it.
Mike