De Professional Scrum Product Owners hebben begrip nodig van alle zaken die waarde toevoegen aan hun producten. De Product Owner training helpt deze kennis te ontwikkelen, van stakeholder management tot release planning en delivery

Meer details van de Product Owner Training.

A customer I was working with asked me to help out with the intake process for recruiting a new Scrum Master and a new Product Owner. I asked them what they had so far. They provided a clear job description describing what they wanted to see from the candidates. They also had a great business storyline describing their goals and ambitions and in what way these impact the people applying for the new roles. They planned two interview sessions and wondered what else could be done to increase chances of finding the right person for the job.

In the past they had created cases for developers. The candidates would prepare these cases at home and present their results, showing their ability to create code. My opinion on this practice is that it makes total sense if you want to test the presentation abilities of candidates, which is not what I want to test because giving presentations is not a main PO or SM skill. We want to know if the Scrum Master is good at doing Scrum Master things, and if the PO is good at doing real PO things. I therefore proposed to create cases like they did for developers, but then for a PO or a SM. We agreed it would be best to prepare real work and let them do that work with the team in a one hour session.

The Scrum Master was asked to facilitate a retrospective with the team. The reason for choosing the Retrospective is because this is the session in which the Scrum Master plays a very important role. The team would then be able to assess the candidates on their ability to listen, facilitate, help the team to formulate action points, personality, etc. Although the Scrum Master is not up to date with all details and does not know the team, he should be able to show his skills by doing a general retrospective using a facilitation format of his choice delivering an improvement action point or deeper understanding of a problem. This will also give him an idea of the team dynamics and will help him to make an informed decision if he would like to work with this team.

The PO was asked to do a refinement session with the team. We chose a refinement because it is such a rich session that requires the PO to take decisions, show his understanding of the domain, work with estimates, deal with stakeholders and team dynamics, etc. To prepare, he was granted access to the acceptance environment to access the product and was given some real wish from the stakeholder, accompanied by a UI design. The stakeholder was present in the refinement session to give more context or answer questions. The work contained unclarities and the information provided was incomplete. As we said, it was real work. We expected the PO should be able to produce a set of sensible estimated user stories within an hour. We were curious to learn what the PO thought of as being most valuable.

The results were great! Experiencing the Scrum Master in action immediately tells you what this person’s soft skills are, how well he can facilitate, if he can manage the time box for delivering actionable items, etc. It is immediately clear for the team if there is a misfit on a personal level too. The Product Owners worked on the same requirements, which was a pretty large chunk of work that had to be split, estimated and ordered. We saw very different results produced by the various candidates. We evaluated the candidates and the results they produced straight after each session. The outcomes were easy to compare because the candidates all worked with the same input material. The candidates that participated all were enthusiastic about this approach.

Downside of this practice is doing the same sessions multiple times for the sake of evaluating a candidate can be a bit tedious. So apply this practice only with the last two or three candidates.

I highly recommend to put job candidates for PO and SM roles in action doing the real work as an addition to job regular interviews. It is a great way (maybe the only way) to learn if a candidate matches your expectations.

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.