13

I keep reading that during Product Backlog Grooming the development team meets with the PM and the Product Owner and as a team prioritizes the features.

Is it ultimately the Product Owner who decides the priority (what needs to be worked on and released first)?

Where does the Business Analyst come into this? I thought it was the BA's job to build relationships with the business stakeholders, learn the vision, learn the needs of the customers and work with the business to determine priority and requirements?

Can someone please clarify, thanks!

Improve this question

7 Answers 7

Reset to default
13

Business Analyst works with the Product Owner and provides him with valuable insights on the value and importance of the user stories, but the PO is still the person who sets the priority of the backlog. The same applies to the the Team's involvement. Team members provide usable information on the technical level to the PO and the PO should be able understand this information and use it when prioritizing the backlog.

Improve this answer
1
  • Another challenges happens at scale i.e. when there are more than about two Scrum Teams working on the same Product Backlog. The PO's job becomes much more about delegation and more about prioritization of these sort of stakeholder management and business analysis tasks.
    – jason.t.knight
    Commented Jan 4, 2016 at 20:36
8

The direct answer is that the Product Owner prioritizes the backlog. It is, of course a little more nuanced than that. In an ideal world, the PO would just sort the backlog items by effort and value to create their priority - and that's usually what happens at first. However, the team is going to provide a lot of input about how the order selected affects their ability to deliver product increments. For example, the team may say that putting one item in ahead of another allows they to deliver them with less overall effort.

The business analyst is in an interesting position. You'll notice there is no BA role in scrum. The traditional role of BA extends into both the PO role when it comes to engaging stakeholders and identifying work that needs to be done but it also extends into the team role when it comes into digging into technical details, database and screen design, and other implementation specifics. The pure scrum approach would say you need to choose to be either the PO or a team member and then follow that role, but with many teams starting off, that isn't possible or practical for a number of reasons. If you're continuing to fill a BA position that extends into both of the roles, I would make two suggestions:

1) Know which hat you're wearing at any time and wear only one. For example, if you're trying to get some user stories ready for backlog refinement, you're wearing your PO hat, so be careful not to get into implementation details. First, you will have real trouble keeping the backlog ahead of the team and second, you take the solution out of the team's hands, reducing their ownership of the work and sense of responsibility. Similarly, if you're working on designing or building the software, keep your team hat on. Switching back to PO unintentionally sends a message to the team that your thoughts trump theirs and again, you lose their ownership (the obvious exception being if the team asks you a PO question).

2) Traditionally the BA on projects is expected to take the analysis and design much further along than Scrum requires. The whole team should own designing and creating the implementation of the user story. In many cases, you may be the person to do it, but the team as a whole should own it and if you don't have time, other team members should step in. The development team should never push that on you and say they can't work on something because you haven't finished design details.

Improve this answer
1
  • New reply to old post, but... taking this further, I would say that ideally, a PO is not needed because the team are experts in the domain, seek validation, and have a good process for prioritizing. I always push my PO-type roles to distribute understanding, ownership, etc. and make themselves obsolete near the "bottom" of the pyramid, even if it will never truly happen. Good things come from it. :)
    – Jeff Lindsey
    Commented Dec 17, 2015 at 14:27
4

The answer is, Yes, No, It Depends, in true agile fashion. :)

So I've been lucky or unlucky as the case may be and have never worked in a company with the Business Analyst role. So I can't comment on Zsolt's answer.

What I do know is that in the agile community we are seeing more and more the concept of the Product Owner Team. And the concept of what I call Pyramid Planning is still very valid in agile.

Pyramid Planning: The idea of several stages of planning with greater levels of detail. The large scale agile model, SAFe, uses this extensively. At the highest level prioritization is done by a business/ strategic team. At my present company (AOL) we us this regularly. As you get closer to the actual development work, the people involved in specific planning change. VPs and Execs decide the four big things that will be done this year, the team will decide just what gets done for the iteration next month. Which brings us to the idea of...

Product Owner Team: Having been a product manager, in a past life, I can say without a doubt that few, if any, product managers get to make all the decisions themselves. They are usually little more that the cowboy desperately trying to hold onto the bucking horse and guide it in the right direction. The Product Owner Team (POT) recognizes this and formalizes it. The POT is made up of the key individuals who can provide the PO with all the data to make an informed decision. A POT will often have, in addition to the PO, an architect, representative of the development team, Ops/IT, customer support and BAs if the company has them. As a team they will review User Stories and prioritize them based on the entire picture, not just a limited business view that often happens if a Product Manager tries to work in a vacuum.

And it is important to note that you need to always engage with the team to get at least a high level estimate for the level of effort. You, the product owner, may think teleporting cars is the most important feature ever. And you may be right, only the dev team will tell you that no matter how valuable it is, it will take a 100 times longer than making a new self-driving car. You always need to factor time into your prioritization and only the team can give you a realistic estimate.

Improve this answer
2
  • There are a lot of interesting ideas in your post, but I'm uncomfortable giving a +1 without the post explicitly stating that the formal framework currently requires a single PO. I think the stakeholders and the team often work with the PO in the way you describe the POT, but in the end the Product Backlog cannot be managed by committee. It must be prioritized by a single person who takes responsibility for its sequencing.
    – Todd A. Jacobs ♦
    Commented Dec 13, 2015 at 21:58
  • 1
    @CodeGnome- You are correct, the Product Owner still owns the final prioritization. However, they are better able to prioritize because they have a team of experts helping them to make those decisions. Instead of a PO working from their own, often limited, expertise, they are working from a whole group.
    – Joel Bancroft-Connors
    Commented Dec 14, 2015 at 18:00
1

On a traditional scrum team, the Product Owner is accountable for ensuring the backlog is prioritized. There is no BA role on a pure scrum team.

The team is accountable for ensuring everyone understands and agrees that the priorities are correct.

The team and the PO together are responsible for prioritizing the backlog.

In reality, there are BA's. What's important is that the whole team agrees and understands who is accountable (makes sure it gets done) for making sure the backlog gets prioritized vs who is responsible (does it).

There are teams where the BA is accountable and in combination with the rest of the team responsible. There are teams where the BA is only responsible and the PO is still held accountable. It depends on your organization and what works best for your team.

You want to avoid situations where 1 person is responsible, since prioritization is a complex problem that benefits from having numerous eyes/brains on ensuring optimal priority.

Improve this answer
0

Some really excellent answers here!

As we're Talking Product Owners, so I'm going to assume Scrum, I'd like add a link - Scrum Guide by the scrum alliance.

The Product Owner is the sole person responsible for managing the     
Product Backlog. Product Backlog management includes:

- Clearly expressing Product Backlog items;
- Ordering the items in the Product Backlog to best achieve goals and missions;
- Optimizing the value of the work the Development Team performs;
- Ensuring that the Product Backlog is visible, transparent, and 
clear to all, and shows what the Scrum Team will work on next; 
- Ensuring the Development Team understands items in the Product
Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team do it. 
However, the Product Owner remains accountable.

As this indicates the Product Owner CAN get the Development Team to do this work. But the Product Owner is Accountable - this is the important factor - accountability.

Improve this answer
0

Depends on the process, chosen for that project.

In real Scrum, the Product Owner is the one that prioritizes the product backlog. However, it is the Development Team that decides how many of the prioritized stories it can fit in the upcoming Sprint.

Usually that would happen in the first session of the Sprint Planning, when the PO presents his choice of stories for the Sprint. The development team then estimates and re-negotiates if necessary the order and amount of the stories they agree to work on in that same Sprint.

So, it is the PO that prioritizes, but it is the development team that has the final saying what goes in the sprint backlog.


A common scenario


1. Sprint Planning - Session 1

PO & Development Team meet and discuss. PO presents the order of all the stories in the product backlog, he wants to see in the upcoming Sprint. Development team

  • agrees or
  • re-negotiate the order/number of stories or
  • refuse to include one or more stories in the Sprint

2. Sprint Planning - Session 2

PO & Dev.Team have agreed on the number and order of stories that will be worked on during the sprint (they have defined the Sprint Backlog). The Dev.Team decides how to work on each story. At that point they no longer need the PO at the meeting.

Improve this answer
-1

It does not really matter who prioritizes the backlog. What really matters is how that is being done: by analyzing risk, benefit and impact of each enhancement. The actual role of the person doing this analysis is of secondary importance in the process.

Improve this answer
4
  • Link-only answer are not welcome on PMSE. Could you add a relevant extract from the referenced link into your answer?
    – Sergey Kudryavtsev
    Commented Oct 29, 2018 at 12:24
  • No worries, I enhanced the answer. Though I feel the original summary "It does not really matter who prioritizes the backlog. What really matters is how that is being done" is a clear and relevant minimum extract.
    – Frank
    Commented Oct 29, 2018 at 16:14
  • You have to disclose your affiliation
    – bummi
    Commented Apr 6, 2019 at 10:07
  • From a Scrum perspective (which this question was tagged with), this answer is factually incorrect. If you want to offer an alternative viewpoint, make sure you and your audience both understand how and why you are advocating something non-Scrum within a Scrum context.
    – Todd A. Jacobs ♦
    Commented Apr 8, 2019 at 2:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.