Over the last weeks I’ve been working on a paper about the role of a Business Analysts within Large Scale Scrum, and I thought I’d write a little post on it too, here it goes.

On the website of the IIBA you can find their definition of a Business Analyst.

liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals


In a Large Scale Scrum organization this definition often results in Business Analysts working as a liaison between stakeholder and the teams. And this liaison role turns out not to be very effective at scale.

A business analyst is not the same as a Product Owner

We know that there is only 1 Product Owner for a product, see the Scrum Guide; but in Large Scale Scrum adoptions, you often see lots of Product Owners although only 1 product is being developed. You can expect to see that each Development Team has its own unique Product Owner (PO) and that a BA plays the PO role. This is an understandable and easy step to take for an organisation; all you have to do is change the role name from BA to PO.

All these BAs stay a liaison between the Development Teams and the customers. And the liaison role introduces unnecessary hand-off; documentation; information scatter; and poor customer understanding by the teams – see my paper Copy Paste Scaling for more details on this.

A BA can play the role of a PO if she has the right market understanding, skills and mandate; but it is generally a bad idea in Large Scale Scrum to have a separate BA play the role of PO for each Development Team. Instead keep it simple, have 1 PO and create true cross-functional teams. 

From recomending to developing

A BA with a responsibility for analysis alone does not work anymore and the reason is simple: Analysis is not something that adds customer value on its own; it is just one of the activities in the end-to-end value chain. So you would like to avoid locally optimising Business Analysis. Instead you would like a BA to be responsible for delivering working product and that they directly work on validation and implementation of the product.

These days it is essential to validate assumptions quickly. Answers to questions like:

  • Are we solving the right problem?;
  • are we solving the problem correctly?;
  • and does the solution add enough value to us?

 requires frequent feedback. 

Therefore, you would like to have a BA as one of the Development Team members, just like a programmer, tester or domain expert are too. Now, the BA can use its expertise, which is essential for success, more effective and help to optimize the whole of product development.

As a Development Team member the BA:

  • keeps a focus on the end result;
  • can see if ides actually work;
  • can adjust rapidly if ideas do not work;
  • can easily share his expertise with the rest of the Development Team;
  • and can take the lead during refinement sessions. 

So, if you want to optimise for speed, agility and learning, it is probably better to have a BA be part of your Development Team and not be a fake Product Owner.

I was coaching a number of teams and their Sprint Reviews were boring status meetings and few stakeholders attended. I see this pattern often at companies and the reason for poor stakeholder attendance is that the discussion about added value happens in other meetings. In this post I want to share a little model based on Impact Mapping and Value Requirements[2] I use to improve team’s focus on value.


Delivering value has always been the priority of agile teams. One of the principles of the agile manifesto emphasises this focus:

“Our highest priority is to satisfy the customerthrough early and continuous deliveryof valuable software”.

This principle sets the focus on delivering value to customers. Value from the customer’s point of view is the benefit they think they will get from using a product or a service. The focus on customer value has led some to measure and track value delivered with user stories. Measuring customer value with value points only goes so far.


User stories are great for many reasons, but a user story is focused on customer value as you can see in the quote below.

“A user story describes functionality that will be valuable to either a user or purchaser of a system or software”

source: User Stories Applied, Mike Cohn, 2004 

If your Sprint Reviews have a lack of stakeholders, maybe it is because you are having the wrong discussions. If your Sprint Review is a demo and only discusses how many user stories were delivered you might have found the problem. The discussion at the Sprint Review should be about “how much value we created?” and “what is preventing us from shipping today?”. It should address the value of all stakeholders not just the customer’s value.

A Product Owner may have the following value questions:

  • Are we solving the right problem?
  • Are we building the right solution for that problem?
  • Are customers willing to pay for it?
  • Can I make money developing it?

For a customer, value questions could be:

  • Does it solve a problem I know I have in a better way then my current solution?
  • Does it solve a problem that I didn’t know I had?
  • Am I willing to use it?
  • Am I willing to pay for it?

A stakeholder could be interested in:

  • Am I making the right investment?
  • Am I reaching my stakeholder objectives?

Answering all these questions by measuring value points on user stories can be challenging. It can work if you are developing a mobile-app, but it becomes harder when you are developing an internal system for supporting a new business process.


In order to satisfy different stakeholders and steer development you need a more fine-grained definition of value and progress. Different stakeholders seek different values There are various levels of outcomes and outputs; I like to discriminate between three levels:

  • The team level
  • The product level
  • The business level.

Value at the team level

I like to see outputs at the team level as potential solutions a.k.a. product increments. The outcomes at the team level are its potential impact on product quality. These are product qualities like usability, costs, maintainability, performance and so on.

Value at the product level

At the product level the quality of the product are merely outputs of the team. Outcomes at the product level are customer behaviour and stakeholder values or happy customers and happy stakeholders.

Value at the business level

At the business level, the happy customers and happy stakeholders are merely outputs to the product. The outcome at the business level would be increased revenue or increased employee satisfaction for example.

In the graphic below you see the three levels and their relationship on outputs and outcomes.

The good part of all of this is that you can measure and receive feedback at these three levels and are therefore able to learn more from your development experiments.


Let’s say you are an airline company and your business objective is to make more money by increasing ticket sales in the current customer base. The expected outcome at the business level is a 20% increase in revenue and of course happy customers and stakeholders. It is decided that one way to contribute to the 20% increase in revenue, is to increase in the sales under frequent flyers from 10M to 11M. At the business level, we end up with an expected outcome of 20% increase in revenue under existing customers. The expected output is a 1M increase in frequent flyer tickets sales.

At the product level the 1M increase in frequent flyer sales is one of the outcomes. Another outcome is happy customers, in this case frequent flyers. In order to have happy frequent flyers it is decided to increase the ease of rebooking. So, at the product level we have as outcome a 1M increase in frequent flyer sales and as output we have an increase in ease of rebooking.

Finally we arrive at the team level. The outcome of delivering an increment is to increase the easy of rebooking. The product quality we are talking about here is Usability. The output is the potential solution ‘Auto-rebooking’ functionality to increase the ease of rebooking.

You now have linked the experiment of developing ‘auto rebooking’ to the expected business outcome of 20% increase in revenue. At the Scrum Team level it is absolutely clear why we are doing the experiment we do. At the Sprint Review you can discuss how much product value you added by measuring Usability. You can also measure, after releasing, if an increase in Usability results in an increase of frequent flyer sales and if the business objective is significantly impacted. You can now design Sprint Goals that add value for all stakeholders and measure progress towards them.