Scrum roles

Scrum Roles

Scrum is a lightweight Framework that helps teams to deliver value. Scrum describes three accountabilities, also known as Scrum roles, that make up the Scrum team: Product Owner, Scrum Master, and Scrum Developers, also sometimes simply known as the development team.

The Scrum Team’s primary focus is to make the best possible progress toward the Sprint goal, which is the single objective for the Sprint. Within a Scrum team, there are no sub-teams or hierarchies. Rather, the team is a self-organized and self-managing unit of professionals. In contrast to classical project management methods, Scrum doesn’t have a product manager or a team leader. Let’s dive into the different Scrum’s different roles and responsibilities.

Recommended e-learning: Learn about the different elements of the Scrum framework and why it works only in its entirety in our Scrum Foundations online course. 

The Product Owner

According to the Scrum Guide, the Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

Product Owner Responsibilities

 This role also holds a lot of accountability, as the name suggests. The PO has three key responsibilities.

Recommended for you: Product Owner Online Short Course

Manage the Product Backlog 

The Product Owner is usually one person who is accountable for effective Product Backlog management. The Product Backlog is an emergent, ordered list of what is needed to improve the product or service. This includes developing and communicating the product goal, creating and ordering product backlog items, and ensuring that the product backlog is transparent and visible at all times. As a result, they often have to prioritize work and backlog items by keeping the product goal in mind. 

Stakeholder Management 

Often the PO has to “fight on both sides”. The Scrum Team often works within a specific time frame (the Sprint). During the Sprint, the Product Owner often needs to deal with marketing, management, or customers in order to prioritize work and maximize value. The PO must be an excellent communicator, as they must be in contact with all stakeholders, sponsors, and the Scrum team throughout a project.

Return on Investment

The Product Owner is also responsible for the return on investment (ROI). They validate the solutions from the end-user’s point of view and verify whether the quality is acceptable or not. 

Product Owner vs Product Manager

Typically speaking, product managers are strategic and focus on the product’s vision as well as the company’s objectives and the market. Product Owners, on the other hand, are more tactical and focus on fulfilling a product vision by managing backlogs and working in cross-functional teams. A good Product Owner needs to be able to take responsibility, as the name suggests, for the success or failure of a project, which means they need to communicate effectively and juggle people’s expectations.

The Scrum Master

The Scrum Master (SM) is accountable for establishing Scrum as defined in the Scrum Guide. The SM helps to increase the team’s effectiveness by enabling continuous improvement and making sure that everyone understands the theory and practices of Scrum, both within teams and the whole organization. 

Recommended Training: Certified Scrum Master (CSM) Certification 

Scrum Master Responsibilities

According to the Scrum guide, “Scrum Masters are true leaders who serve the Scrum Team and the larger organization.” 

Improve the Team’s Effectiveness

The Scrum Master should create optimal working conditions for the team and keep these constant throughout the Sprint. This includes making sure that the team follows the Scrum Framework and understands all the elements of Scrum, including the five Scrum Events. They should have a comprehensive knowledge of Scrum and be able to act as a servant leader by creating the ideal environment for teams to thrive.

Remove Impediments

A Scrum Master is tasked with creating an environment for teams to thrive. They should aim to get rid of all possible impediments – or problems – that might disturb the work of the team. Usually problems can be classified in three different categories:

  • Problems the team cannot solve: For example, there may be a lack of necessary hardware or software, or a stakeholder such as a manager is making unrealistic demands of the team. 
  • Impediments related to organizational structure or strategic decisions: There are many examples of this. Perhaps the office or virtual workspace is not adequately set up to enable teamwork: maybe there is an unreliable internet connection, or meeting rooms aren’t available. Another common example is that the Scrum Master is viewed as being a project leader, and the team isn’t viewed as their equals. 
  • Problems related to the individuals:  This may include technical issues like computer crashes, or delays resulting from team members needing to wait for input to complete a task they’re unable to handle alone.  

The Scrum Master can’t and shouldn’t solve every problem alone, but they are still responsible for guiding the team towards solutions and removing impediments. This task often takes up a lot of time and requires great resilience and the ability to care deeply for the team. 

Serve the Whole Organization 

The SM should lead the organization in adopting Scrum. They should help employees and stakeholders enact and understand Scrum so that it can be successfully implemented. They may need to coach and advise in these instances.


Scrum Master vs Project Manager

The most obvious difference between a Project Manager and a Scrum Master is represented by the name itself. A Project Manager manages the project and sets the tasks, while the SM is in charge of ensuring that the team adheres to the Scrum framework. The Scrum Master does not interfere with the decisions of the team in terms of what they do, but acts as an advisor to the team when it comes to how they work. They only interfere when any participant in the project does not align with the principles of Scrum. A project manager, on the other hand, often gives directions and takes responsibility for the completion of tasks.

The Scrum Developers

The Developers, or sometimes simply referred to as the Scrum Team or development team, have all skills necessary to create a valuable Increment for each Sprint, and they self-manage. 

Scrum Developer Responsibilities

This team typically consists of three to five people and the specific skills needed by the Developers are often broad and will vary with the domain of work, however, they typically share the same set of responsibilities within a Sprint.

Create a Plan for the Sprint

The developers do not simply receive tasks from a project leader; they are self-managing and decide how many User Stories they can accomplish in one Sprint themselves. They create a plan for the Sprint, the Sprint Backlog (which is composed of the Sprint Goal, the Product Backlog items selected for the Sprint) as well as an actionable plan for delivering the Increment.

Manage and Execute Their Work 

The developers instill quality by adhering to a Definition of Done and work to ensure that they meet that standard. They may need to adapt their plan to reach the Sprint Goal and always hold one another accountable during the Sprint. 

Scrum Developers Work Differently from Traditional Teams

Developers in a Scrum Team decide on their tasks and are responsible for the execution of them – the team becomes a manager. The Scrum Master does not need to delegate all the work and plan the project

Get The Most out of Scrum

Scrum is simple to understand, but it can be difficult to master. Scrum is purposefully incomplete: It just defines the rules of the game, like the rules of a sport. That’s one reason why Scrum is hard to master: you need to know so many things outside Scrum to make it work successfully. 

And if you need help implementing Scrum in your organization, get in contact with us.

Daily Standup

How to Revive Your Daily Standup

The daily standup is a fundamental part of Scrum rituals, but it’s also one of the most misunderstood. At agile42, we’ve been coaching organizations to facilitate these Scrum events for 15 years. We’ve guided hundreds of teams towards making these 15-minute sessions stand out as a useful, valuable, and enjoyable event. Here’s our guide to what a daily standup actually is, along with some of our tried-and-tested methods to bring life back into the daily standup. 

Recommended online course: Facilitating Scrum

What is a daily standup?

The daily standup is a 15-minute meeting that takes place every day. Although the meeting is not exclusive to Agile methods, it’s an integral part of many Agile frameworks and methods including Scrum, Kanban and XP. 

Daily standup vs Daily Scrum

While the terms “daily standup” and “Daily Scrum” are used interchangeably, there is technically a difference. The Daily Scrum is how it is referred to in the Official Scrum Guide and makes up one of the five Scrum events. The daily standup is a more general term for a quick 15-minute catchup, used in Kanban and other settings outside of a Sprint.

Why is a daily standup meeting important?

It is important to understand the purpose of the daily standup, so that you can make sure this Scrum event is a good use of everyone’s time. The two key purposes of a Daily Standup are: 

  • to agree as a team on how to deliver the most value in the next working day; and
  • to inspect and adapt the sprint plan if necessary, in order to deliver the most value in the sprint.

If you’re having trouble keeping your daily standups, it also helps to remember the Lean and Agile principles that guide these events: 

  • Focus on outcomes over output (or results over activity)
  • Focus on priorities
  • Emphasize team ownership of results over individual assignments
Daily Standup Meeting

Photo by Parabol

How to run a daily standup

The standard format for a daily standup consists of each team member answering three questions: 

  • What did you achieve yesterday? 
  • What will you achieve today?
  • What impediments are in your way?

This format is used widely with varying degrees of success. While it is the original, traditional format, you don’t have to use it if it doesn’t work for your team. Each team has its own needs and preferences, and as long as you’re focusing on what’s important – like communicating, prioritizing, and managing the flow (not the people) – you can change the format to better suit your needs. The traditional three-question format can also really easily devolve into a mere status update meeting, failing to achieve the purpose of the daily standup and failing to embody its principles. If that’s happened to your dailies, you may need to find a way to revive your standup. 

How to revive your daily standup

If your daily standups have turned into status updates, your team is disengaged, and you’ve lost touch with the principles of Scrum that guide the concept of these meetings, you’re not alone. Many organizations have difficulty running effective standups, and their teams feel like they’re not an effective use of their valuable time. If the team is not finding the meeting useful, you need to find the root cause and fix it. Here are 10 ways you can bring life back into your daily standups, and reap the benefit of this crucial Scum event. 

Think of it like a sports huddle 

Jeff Sutherland, one of the creators of Scrum, says “The idea is for the team to quickly confer on how to move toward victory—i.e., complete the Sprint.” It may help to think of it like a huddle before a sports game: the team comes together to re-energise, encourage, and strategies for the day. It’s not a chance to chat about training schedules, travel expenses, discuss goals for the year, introduce new players, or any of the other concerns a team might have. It’s a quick, razor-focused strategy session for the match they are currently playing. 

Ask the right questions

If your daily standups are not working well for your team, and don’t feel like a good use of their time, it’s important to discover the root cause of this. Get someone from the team to observe the meeting and think about the following questions, to guide them to the cause of the concern: 

  • Situation: Does the team report to itself or the ScrumMaster? Is the situation presented honestly? Do they have facts and information in front of their noses? Is the granularity right?
  • Focus: Is the goal clear? Is the team focusing on getting the next backlog item done, rather than ensuring everyone has work for the day? Is there a lot of bureaucratic overhead?
  • Speaking: Does everyone get the opportunity to speak? Who speaks most, who is most silent? Do people listen intently or are they just waiting for their own turn? Are people supporting each other?
  • Decision-making: Who makes decisions? Is it one person or the whole team? Do they evaluate multiple options? Are decisions based on facts? If they make guesses, do they go on to validate the decisions before investing time?
  • Language: Does the team have their own “slang”? Does the body language support the verbal message? If you’re running virtual standups, are cameras on or off?
  • Trust: Are they showing respect for each other and for other teams? Are they having fun together? Can they bring up difficult topics? Are they showing courage?

Focus on the work, not the individuals 

The focus of a daily standup should be on stories and priorities, not on any individual’s to-do list or performance. Since you’re talking about the work and flow itself, and not about individuals, it is possible that one team member may speak a few times while others may speak less (or not at all) some days. This is okay: it is not a status report or a chance to check up on productivity; it is a chance for the team to make sure they have everything they need to achieve the outcomes they have in mind for that day. 

Brush up on your Scrum foundational knowledge

You simply can’t facilitate a standup well if you aren’t well-versed in the principles of Scrum. Consider taking an online Scrum course, to make sure you are being guided by the right principles and practices. 

Online Scrum Courses

Keep it to 15 minutes

The 15-minute time limit of a daily standup is there for a reason. Set a timer, and make sure you stick to it. This keeps the meetings productive, focused, and to-the-point. If other distracting conversations come up during this meeting, you can make a note of them, but do not discuss them now. Which brings us to our next point… 

Use a parking lot to stay focused

Use a “parking lot” for discussions that are too long or do not concern the whole team. You can have a literal whiteboard in the office, or a virtual space like Miro or Trello. When the standup veers off course, and other topics emerge, simply note them down for later and move on. Remember that anyone has the right to call “timeout” on distracting conversations; this is not the job of a leader or Scrum Master. 

Make sure these conversations and concerns don’t get forgotten forever. You can stick around after the standup to continue talking about them, or perhaps set aside a few minutes in your Retrospective at the end of the Sprint or project to do so. You can use a voting system to determine which parking lot conversations to prioritize and analyze. Keep the stand-up focused, finish it on time, and then anyone who needs to continue the parked discussions can do so after the meeting is over. 

Agree on the Scrum Master’s role

It is not essential that the Scrum Master attends this meeting, but it is also allowed, if that works for the team. However, it is crucial that the daily scrum is for team members to connect, prioritize, and plan for the day. The team should be speaking and making eye contact with each other, rather than the Scrum Master (or any single individual). This is a good way to tell if there’s a problem in the way the standups are running.

Agree on the Scrum Master’s role, and what works for your team. Should they attend? If so, should their key focus be to ensure that everyone remains focused and no external people are disrupting the purpose of the meeting? Or perhaps they should simply observe, or be available in case they are needed to help with any particular impediments.  

Change up the format

The traditional three-question format might work nicely for you, and that’s fine. But there are a number of other tried-and-tested formats that we’ve used at agile42 that can boost the effectiveness of the standup, depending on the team. Here are a few examples, suggested by some prominent thought leaders in the Agile community. 

Walk The Board

Jason Yip, Senior Agile Coach for Spotify, uses the “Walk The Board” format for standups. It is a great way to keep the focus on the board. Here’s how the format works: 

  • Gather around your team’s board. 
  • Start with the highest priority story/feature in progress.
  • Ask what we, as a team, can do to get that story done (per our Definition of Done).
  • Ask what is blocking us, as a team, from getting the story done.
  • Repeat steps 3-4 for the next few priority items, up to your team’s WIP limit. 
  • To finish, validate that everyone on the team has been heard and all are focused on the top priority stories.
Kanban Board Daily Standup

Photo by Parabol on Unsplash

The Sprint Goal

Olaf Lewitz, veteran and leader in the Agile community, suggests using a slightly different set of three questions: one that shifts the focus to the team and the sprint goal, rather than each individual’s list. He suggests asking:

  • What did we (as a team) achieve to get closer to the sprint goal?
  • What’s blocking us from focusing on the sprint goal?
  • What do we agree on doing today to make sure we reach the sprint goal?
The Two Plus One Questions

Founder of agile42, Andrea Tomasini, starts his standups by asking each person the first two questions:

  • What have I achieved since last time?
  • What impediments are still in my way?

Based on these answers the team as a whole can devise the best plan for the day. Finally, each individual can clarify her/his commitment to the team’s plan for the day by answering the third question: What do I commit to achieving today?

The Story of the Day

Dave Sharrock proposes a single question, to ensure the team remains razor-focused on the sprint itself. The question is, simply, “Which story will we finish today?”

Use a ball to add dynamism 

If you’re finding your main concern with standups to be that there is low energy and engagement, and you’re sure that you’re using the right format and sticking to the time limit, you can try adding a ball to the mix. Use a stress ball, tennis ball, or really anything you can throw around your workspace (without breaking things).

Once each person finishes speaking, they can throw the ball to the next person to indicate that it is their turn. This can make things a little more lively and fun, and it has the added benefit of keeping people listening and paying attention, since the structure is a little more unpredictable than going in a circle. If your team works remotely, you can use a version of this technique relatively easily. Simply say who you are passing the ball to, and that person can use your video conferencing tool’s “Raise Hand” feature to indicate that you’ve “caught the ball”. As an added bonus, nobody needs to know how good (or bad) your real-life catching and throwing skills are. 

Check the granularity of your tasks 

If you’re finding that your daily standup often runs over the time limit, and they’re defined by impediments, high levels of stress, or not meeting daily goals, there might be a problem with the granularity of your tasks in the first place. The tasks set each day should be achievable in a single day, to match the frequency of the meeting and foster collaboration rather than any kind of competition.

agile42 offers remote Scrum training

We offer Certified Scrum Master (CSM)Advanced Certified Scrum Master (A-CSM)Certified Scrum Professional-ScrumMaster (CSP-SM)Certified Scrum Product Owner (CSPO)Advanced Certified Scrum Product Owner (A-CSPO), and Certified Scrum Developer (CSD) training, in live remote sessions with our experienced certified coaches. If you need help, coaching, mentoring, or training, don’t hesitate to reach out!

a picture of a cell phone and parts

Techniques for Breaking Down Technically Complex User Stories

Breaking down user stories to fit into a few days of work and still deliver value is a vital component of Agile and Scrum. This is what allows the Scrum team to get fast feedback on the work they are doing to ensure it aligns with customer needs.

So what happens when the Product Owner can’t break down a story any further and it’s still too big to be manageable in a sprint? This creates a very difficult problem that the Product Owner and Development Team must work together to solve. 

In this post, we’re going to break down this user story:

As a data center technician, I want to be able to configure VLANs on a network switch from a web interface so I can easily make changes to any switch without being trained on the switch configuration process.

This kind of user story can be very challenging because there are a lot of complexities and unknowns contained within it. For example, the team might know that the switch must be configured through SNMP, but may have never used it before.

Looking at the Pieces

To start us off, we need to stop thinking about the story as a single thing and start looking at the pieces. So, let’s set aside worrying about value and user stories for a moment and break down the steps.

One great way to do this is to take a stack of sticky notes and have the team draw the steps in the process of the user story on each sticky note, then put them up on the wall. This lets the team quickly brainstorm the parts of the user story together. The picture below shows how this might look for our example:

sticky notes visualization

Notice that these stay very high level. The goal is not to create a detailed plan of how this will be implemented, but rather to create a visualization of what is involved with the story. A good rule of thumb is that the Product Owner should still be able to follow along with minimal explanation from the team. This will be important for the next step in the process.

It’s also important to remember that this doesn’t have to be perfect. If some of the steps are slightly off or missing, that’s ok.

Finding the Value

Now that the team has established many of the parts of the story, we can start looking for groupings with value. This is a collaborative conversation between the Product Owner and the team to identify what will add value and what will be technically plausible.     

Grouping tasks

You can see that a few things came out of this conversation. We’ve grouped the display of switch data into one story and the configuration change into another story. We’ve also de-scoped some of the steps. The caching has been set aside, and the Product Owner understands the performance impact that has. 

We also decided that testing the change could be very complex and agreed that a simple validation would be sufficient for technicians to safely use the software, but we might keep another story in the backlog for something more robust later.

Finally, the conversation led us to realize that there might be some additional work around selecting which switch to manage as well as supporting multiple models and manufacturers. This functionality has been moved to other stories in order to provide a more manageable scope for the read and edit stories.

A Different Way to Look at Value

It is very common for teams to become accustomed to looking at value as a full feature that you can package up and sell to a customer – complete and production-ready. While not unreasonable (and not always wrong), this mindset can sometimes make it difficult to break down these kinds of stories. 

If we look at the Agile Manifesto, we don’t see any references to terms like “production-ready” or “sellable”. Instead, we see terms like “working software” and “collaboration”. So when we look for a story to have value, we want to see that we’ve created working, functional software and that it helps us collaborate with our customers and users and helps us learn something about the software we’re creating.

If we look at our groupings above, we can see that none produce documentation, mock-ups, or processes as their deliverable. For example, if we took on the update story first, we would have a simple interface that actually updates the VLAN on a given switch. This doesn’t solve the whole problem, but it lets us put real software in front of the users to see how they use it. In doing so, we may find that the user wants to see what VLANs are already trunked to the switch to select from. This not only tells us that we need an enhancement to the work already done, but it may also influence how we collect and store information from the switch in our “read” story.


Through this process, we’ve turned one large, complex story into five much more manageable stories:

  • As a technician, I’d like to see the current switch VLAN configuration.
  • As a technician, I’d like to be able to save new VLAN configurations from a web interface.
  • As a technician, I’d like to be able to select which switch I am managing.
  • As a technician, I’d like to be able to manage multiple switch manufacturers and models.
  • As a technician, I’d like any automated changes to be validated with robust testing.

All of these produce valuable, working software that helps us collaborate with our customers. They are now ready to be prioritized in the backlog and worked through just as any other user story.


book lot on table

Thesis about the Scrum method as used by agile42

Last month, Inga Geitmann’s thesis, “The Scrum Method as an Instrument of Lean Management and Their Implementation,” was published and is now available all over the world… here is a small summary:

“It ́s necessary to optimize working processes because of the economical benefits and it increases the lastingness of resources and working overhead. Methods especially in the software development were created to help organizations increasing their output while reducing costs. This is out of the economical principle where the idea is from to produce the highest output with less input. The scrum method is an agile method out of the lean management and was created by Toyota. This method was taken over and adapted from the car industry to the software development. Today a lot of big companies work agile with scrum. The increasing trend of using scrum and other agile methods shows the demand of reducing costs in times of uncertainly financial markets. The implementation of scrum through within a customer shows the empiric way how this works.”

Check here for more information and to purchase the book online.

stainless steel tool on gray sand

Kanban and Scrum

In August last year Gartner signalled the death knell of Waterfall. All the evidence over the last 25 years points to some form of Lean-Agile method as the only sensible way forward for managing knowledge work. Kanban and Scrum (together with eXtreme Programming) are the pre-eminent Lean-Agile methods. I would argue that any investment you make in learning these will be the best investment you can make for your career and also the best investment your organisation can make in ensuring business sustainability in the long-term.

You might think it strange that a company named Scrum Sense would talk about Kanban. The truth is that Kanban was a baby in diapers when Scrum Sense started, while Scrum was already the de facto standard in the Agile world. When Maritza van den Heuvel approached me in November 2009 about the possibility of hosting David Anderson in Cape Town I jumped at the opportunity. He visited early in 2010 and we had a great time exploring this new process with him. We learned a lot and I’m tempted to say that we also helped clear up some mis-conceptions about Scrum.

Three years have passed and Kanban now has a significant presence in the Lean-Agile world. The latest worldwide Agile survey places Scrum and Scrum hybrids (most commonly Scrum + XP) first with 66% of the Agile market and Kanban second with 24%. Impressive growth in just about 5 years. Why is this?

As usual, there are some good and some bad reasons. Let’s start with the bad. Many organisations that attempt to ‘do’ Scrum are not actually willing to make the adjustments to their ways of working, ways of managing and company culture that are needed to realise the hoped-for benefits. Scrum is not the silver bullet they hoped for. So some look for the next shiny thing…and discover Kanban. By now, a number of these organisations have also dumped Kanban in search of something easier. One client of mine who did this has largely gone back to Scrum.

There are good reasons too. I see organisations trying to use Scrum to manage work that is really not complex, sometimes repetitive and whose arrival rate is highly variable. Not conducive to being planned in week- to month-long fixed increments. Much more suited to being handled using clear policies and SLA’s.

By now you are asking yourself what the differences are between these to Lean-Agile methods, and where to use what. This is, naturally, a non-trivial question. A good starting point to seek answers is Henrik Kniberg and Mattias Skarin’s free mini-book.

My message is this: if you want to be equipped to make good decisions in the future Lean-Agile world you need to educate yourself in both Scrum and Kanban. And along the way you will realise that you need to develop your so-called “soft” skills and learn how to manage organisational change too.

aerial photography of people

Tips for the beginner Product Owner: How many PO?

Basically, this article is about why it is a bad idea to try to counter a dysfunctional situation by adding more people to the job.

A phenomenon that I encountered often is that companies tend to hire more Product Owners when their setup with one does not seem to work. Can the reflex to just hire more people when the existing ones are not doing what is expected from them help?

Before we take a deeper look into what can go wrong, let‘s summarize how it should be. The three main qualities of a PO are:

  1. Availability
  2. Knowledge
  3. Authority

The Product Owner needs authority. When he says something and gives information to the team, that should be valid and hold. If he cannot say anything because either he does not know or is not allowed to make a decision, this is a major dysfunction.

In order for the Product Owner to make a decision, he needs to be knowledgeable. He needs to know about the product and the product domain. He needs to understand his customers for whom he is building the product, so he needs to be in contact with them. Without knowledge, his authority will not hold and he will lose the ability to make decisions.

And finally, he needs to be available for the Team Members and Scrum Master if they have questions. As well as for the stakeholders when they bring new ideas to the table or have concerns. The best PO is of no use if he is not there to answer a question.

All these qualities enable the PO to optimize the Return on Investment, for which he is responsible. Being responsible also means (apart from the burden) being able to act or decide on one‘s own without supervision. If you are dissatisfied with the work of your PO, the first thing that you should look into is: Is your PO really empowered and can she ultimately shape the ROI? Does she have the tools, like a clear product vision and business values attached to product backlog items? Is the team stable and is she the only channel from whom the team can pull product backlog items?

Often occurring problems after a transition to Scrum is that there are still managers that give direct tasks to members of the team, overrule the decision of the PO or do not really allow him to make decisions. Often, the PO is not allowed to talk directly to customers and stakeholders, so someone else becomes the main source for information that the PO depends on. Lastly, another problem is that the PO is not solely a PO but also responsible for a multitude of other tasks, reducing his availability and focus on the product.

If one of these things is happening, it does not matter how many people are sharing the PO position, it will not get any better.

Normally, one PO can deal with one Team (5-9 developers). Under rare and complex conditions, it might be a good idea to give him a business analyst as an assistant, but at least as often, a PO might also be able to deal with two teams at once. By adding more POs to the job, you dilute the ideal „one face to the team“. If the Backlog is set up as suggested and the team is following the Scrum rules, this will work out.

So before you decide to add more people to the PO position, think about how it could help and if there are no other dysfunctions that need to be solved if your PO tells you that he is overloaded.

Conditions, where it is a good idea to put more POs on the job for one team, is when you have a lot of „disruptiveness“ of the business and have to work out different „branches“ of strategy or be prepared for quickly opening opportunities. Another one may be a highly complex outside world with many different stakeholders that you need to care for. When you should do this, keep in mind that you need a shared responsibility for the ROI and a clear distinction of who is responsible for what.

Tips and Tricks for the beginner Product Owner

Most people are afraid to fail. Shame is at the core of the fear of failure, psychologists say (see Dr. Brené Brown @TED). The problem with fearing failure, though, is that it does nothing but help you fail.

In our western culture, shame is a driver to get others to do things. By using shame and guilt as tools, we do not only burden us with an emotional baggage that is wearing us down emotionally, but we also create a lot of dysfunctions as we hide mistakes in order not to be blamed.

Transparency and courage are values shared by most of the agile approaches, Scrum in particular, the opposite of shame and guilt. We can choose to try to live our lives on our own terms: either by trying, failing and learning or by remaining in the swamp of shame and guilt and not improving. When you feel guilty and ashamed, you behave accordingly. Your mind will keep thinking about what happened and will not allow you to change anything as this would mean acceptance of the failure.

If all went well the first time we tried, we would never ever get any better. As we strive for perfection, we should embrace failures as they give us the chance to grow. Inspection and adaptation require reflection on things that could have gone better. From my experience, once people accept that they basically constantly „fail“ in the way of retrospectively not having chosen the best approach for what they wanted to achieve, they harness the incredible power of creativity and courage and gain the intrinsic motivation to do better at every future step (see Drive).

Shame is a tricky concept and a very useless one too. It has been rooted deeply in our society for maybe longer than a millennium, and that is by far too long a time. As eastern (buddhist and hindi) cultures show us, there is no need for that concept. So stop seeing yourself as a bad person because you did something wrong. Consider yourself lucky that you were given the opportunity to change your future behavior.

So accept that you could have done better, every second of your life, If you had had your current knowledge. You did the best you could, and given the situation at hand, that‘s all you could have done anyway. Wouldn’t it be awesome if we recognized a few of these „failure moments“? Wouldn’t they be an evidence that we have learned something and we can harness the power of learning to improve?

Throwing the concept of guilt and shame overboard is the first step in the direction of good agile risk management. We know that all of us could have done better constantly. So after we accept that fact, we can think about ways to make the biggest mistakes transparent.

So why should we embrace to fail fast? When diving into a new project, I am often confronted with a situation where the management fixed the time and release date, the scope of what should be released and also the quality in terms of SLAs. The first question that I ask under such conditions is: „When do you want to know how badly you are going to fail?“

While the question might be a bit confrontational, the discussion thereafter is awakening most of the time. If the „iron triangle“ (scope, time and quality) is fixed, than it is better to know as fast as possible if the plan is off or not, so that we can react and soften the damage.

As a manager, the worst thing that can happen are surprises for which expectations management is key. Agile methods are the best tool I know to get the most trustable and fast results. Worse than having bad results is having bad results late.

From my practice as a Product Owner, you need a tool to manage releases, not only Sprints. So what I do is to set up a release map and give the developers some overview about the planned high level requirements. In return, I ask them to give me a rough relative estimation about the effort of each of those requirements. Once the first requirements get broken down to little pieces, and the little pieces get estimated, I start knowing more and can do recalculations. With every completed Sprint, I gain knowledge about the progress and even in very large projects, it does not take long to get a good idea about: when it will be finished, or if we need to tighten the scope. This helps  significantly when dealing with multiple stakeholders. Particularly, conversations tend to get way more concrete when I am approached to enlarge the scope. It is easier and faster to forecast the impact of any given change.

So embrace failing fast and don’t fear to be ashamed! Every failure is a new learning opportunity if you accept it as such. Once it is there, you cannot change it anyway, but you have the chance to make the best out of it—learn something from it.

man holding incandescent bulb

Tips and Tricks for the beginning Product Owner

Envision a vision for a better PO

I want to point out that a vision is a necessity. The Product Owner is not going to do a good job without one. The product vision is not part of the Scrum framework. Nonetheless it is often mentioned in the Scrum literature as something that is a prerequisite.

In my experience, most companies lack a vision for their products. On rare occasions,  there existed a product vision, but it led a gloomy existance in a dusty drawer.

A good product vision is short, concise, broad, understandable and most important – engaging! With a good vision in place, everybody in the company will be aligned to the same goal.

Make it clear what you build, what your target audience is, what is the single uncompromiseable feature and what are other features that distinguish your product from your competitors’. Make every sentence and word matter, not longer than an abstract. The book from Geoffrey Moore “Crossing the Chasm” is a great source to learn how to write a vision statement properly.

Why is the product vision a vital tool and not just a toy for esoteric trainers? Imagine the perfect Product Owner. She has the authority to substitute the customer directly when facing the development team when a question arises. This can be accomplished if she has a very good relationship with the customer and knows his wishes, the product and the environment very well. – Even without a product vision.

Now imagine that this Product Owner has more than just one customer. She would need a split personality with a shared knowledge and understanding. And the stiuation gets even worse with three or more customers. And now keep in mind that building a product does not just mean to fulfill the customers‘ wishes. It is about building a product with many other stakeholders like development and marketing as well as juggling with internal requirements and restrictions.

The product vision is the shield for the Product Owner. Many dysfunctions in companies arise because there is no product vision. The common tragedy that follows is that many opportunistic moves undermine the product integrity. The product loses its identity. Nobody knows anymore what makes it stand out, what makes it different, marketing does not know what to advertise about the product, developers are not proud of their product anymore and stop taking care of it. In the end you have a bunch of people who try to hold it all together until there is no more money to squeeze out. The end of the product life cycle is reached. The vision is the tool to align the goals of all stakeholders and allow the Product Owner to challenge and also motivate the team.

So help yourself and the team and forge the tool you need to motivate and keep the integrity of the product instead of whining because it all falls apart.