Tag Archives: business analysis

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.


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.

Business analysts play an important role: They usually act as the link between the business units and IT, helping to discover the user needs and the solution to address them. In Scrum, there is no business analyst role. So what happens to the business analysts?

Option 1: Business Analyst Plays the Product Owner Role

One option for a business analyst is to take on the product owner role, as the following picture shows.

I feel that this option is often a natural extension of the business analyst role. But it usually implies change: A business analyst turned product owner should now own the product on behalf of the company, and be empowered to decide what the product should look like and do, and when which functionality is released. The individual usually also has to learn new skills including leveraging product increments to understand what users need and how their needs can be best met, grooming the product backlog, and writing user stories.

Option 2: Business Analyst Works as a Team Member

The second option for business analysts is to work as team members. This is option is depicted by the following picture:

Business analysts working as a team member often help their peers groom the product backlog. As grooming is a team effort in Scrum, analysts working on the team take on additional responsibilities, for instance, working closely with the testers or the technical writer. As a business analyst on the team, you should hence expect to pick up new skills, broaden your expertise, and be open to work in new areas.

Avoid the Proxy Product Owner Trap

A common mistake is to deal with the role of business analysts in Scrum half-heartedly: Business analysts are neither play the product owner role nor are they team members. They rather end up as proxy product owners, a go-between the real decision maker and the development team:

Using a proxy product owner is not well suited for delivering new features: At a client of mine, the head of a business unit was asked to take on the product owner role for a new product. As he struggled to spend enough time with the team, the business analyst stood in as a proxy. While the analyst did all the detailed grooming work, the business unit head decided about the product features and when which functionally was released. What followed was an increase in miscommunication, a slowdown in decision making, and a decrease in productivity and morale.

If, however, your objective is to maintain an existing product by delivering small, incremental releases, then you may want to continue working with your existing roles and consider employing a linear, Kanban-based process, as I explain in my post “Choosing the Right Lean and Agile Innovation Practices“.


Scrum is not bad news for business analysts, and the individuals still have a job to do. But just like other specialised roles, the work of a business analyst changes in Scrum. Analysts either play the product owner role or work on the team engaging in a broader range of activities.

You can find out more about business analysis in Scrum by attending my Certified Scrum Product Owner training course or my Mastering the Product Backlog training course.