User Story Modelling

Posted on Wednesday 22nd June 2011

Summary

User stories are great at capturing product functionality in isolation. But they are not well suited to describe the interactions between different features and to describe workflows. This blog posts shows how context and activity diagrams can used successfully to complement individual stories.

13 Flares Filament.io 13 Flares ×

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 express the relationships between different features and to describe workflows.

To show how different stories fit together, 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 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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, 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, put them in a context and connect individual epics and stories. Any model related to user stories and epics should be the outcome of a conversation – and never replace it.

13 comments on “User Story Modelling

  1. […] Workflows and models don’t fit into a linear, flat product backlog. Consequently, many Scrum teams ignore them. While requirements modelling should be applied lightly in an agile context, teams often benefit from connecting individual stories and epics, fro instance, by showing how the user roles interact with the epics. The same is true for workflows: It’s often helpful to look at a user story sequence to understand how a user interacts with the product and to explore the resulting user experience. If requirement models and workflows are helpful to develop your product, then add a model area to the product backlog board. Like the constraint items, the models and workflows are not estimated. But they are also not included in the definition of done, as they simply elaborate stories and epics. (I describe user story sequences and workflows in more detail in my post User Story Modelling.) […]

  2. Mike Cohn says:

    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

  3. 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?

  4. Arran Hartgroves says:

    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?

  5. 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.

  6. Thanks for the guidance, much appreciated.

  7. 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!

  8. […] want to explore the anticipated interaction of a user with the product, and to capture it as an interaction diagram or workflow. Put the resulting artefact on the board’s model […]

  9. […] I employ user stories, constraint cards, design sketches, and workflow diagrams. […]

  10. […] Scenarios, workflow diagrams, and storyboards are all great technique to capture the details of the user interaction. […]

  11. […] The user journeys – scenarios, workflows, or storyboards – are a great hunting ground for epics […]

Leave a Reply

Your email address will not be published. Required fields are marked *

* Copy This Password *

* Type Or Paste Password Here *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>