Sunday, September 16, 2018

An open letter to all product owners | SupremeAgile

Dear Product Owner,

Your job is to ensure that the product backlog is always in great shape. This is your responsibility to your team. Throughout the years I’ve seen you take your role and abuse it by not focusing on what is important for the success of your team. If you want to succeed in your role, please focus on the things that really matter to the team. By this I mean:

Clear requirements

Each story that you add to the product backlog should reflect a customer requirement, and it’s your job to ensure that the story reflects this. I expect to see from you a clear definition of what the team should develop to meet your request. Dear PO, sometimes you fail to do your job and share PBIs that are incomplete because you were too busy with other, less important things. Remember that this is what is expected of you as the focal point between the team and the customer. Dear PO, please do your work and ensure that the team gets solid and clear requirements, so they do not need to guess what you wish for.

Definition of done (DoD)

Definition of done is not optional for you to decide on; the team needs it to understand what they have to do to fulfill your vision. How can you expect the team to succeed if you cannot provide a mandatory thing that will reduce errors and miscommunication?

Your responsibility as the team’s PO is to work with the team to create and approve both the feature and the stories’ DoD. This is just the way it is: you just don’t have the privilege to say that it’s less important or obvious and have the team figure it out.

One thing that I want to say regarding this issue is that I trust you not to use a generic DoD that you created two years ago and apply it to a new project without reviewing it first. I know that you are a hard worker; please respect yourself and your team by doing the simple things that they expect from you.

Technical stories

Dear product owner, I know that you want to succeed, and there is no real reason for you to add technical stories that you absolutely have neither the knowledge nor the experience to write. But it’s not a shame for you to learn your product, and by that, I mean the technical aspects of the product. I don’t demand you be on the same level as your development team, but at the very least you should be able to review the story and make sure it makes sense for the team. Learning will allow you to create a better story that the team can actually accomplish because you understand what you’re asking for and whether it is possible for the team to deliver it.

Now, I know that for some POs this is a hard thing to ask. So the only thing I can say is that at the end, it’s up to you to decide whether to take real ownership on your deliverables or whether you’re just acting as a basic proxy between the team and the customer.

Live and let live

Dear product owner, I know that there are a lot of expectations from you to deliver. After all, you are the one who interacts with the customer, who sometimes puts great pressure on you. I understand it, I truly do. But this does not give you the right to interrupt the team during the sprint with "small" urgent items that the team must deliver just because there is some pressure on you. I don’t have any complaints about changes that you want to make once the team is already committed to the work (this is agile after all), but there is a difference between working with us to understand how your requests will impact our commitments and just adding PBIs to the sprint without considering how it may cause us to fail. 

There is nothing wrong with collaboration

If I were in your shoes, I would use the vast knowledge of my team in all aspects related to my role. How can they contribute, you ask? Well, they can help in the creation of the technical stories or help with the DoD or just become more motivated to help you accomplish your vision because you collaborated with them.

Another aspect related to collaboration is your participation in the sprint meetings. Now, I know that sometimes it may seem less important to you, but know that your team needs you. I expect to see you at the daily scrum meetings to see team progress and the problems encountered on the way to accomplish what they promised you. Refinement meetings should be with the team; this will help the team understand and determine rough estimations that can change your prioritization. Believe me that the team will greatly appreciate the chance to reduce the time of the planning meeting.

You are the master of the review meeting, but it’s also your chance to build a strong committed team by sharing productive feedback. You will not achieve anything with negative feedback. Retrospectives? I know that in some cases you are not invited because it’s a "team" event. But I believe that you are part of the team and therefore must take part. I know that you feel that it’s not related to you, but I promise that you will see that you can become a highly effective contributor.

Planning meeting? Yes, you usually take ownership on the first part (story review and setting the iteration goal) and fade out while the team starts to estimate and add their tasks. This is your chance to collaborate with the team and answer all open questions, change the original prioritization, and break down stories that the team cannot accomplish in the upcoming sprint.

Why don't you focus on our team?

Dear product owner, I know that you want to show that you have the skills to handle more than just one scrum team, but to be honest you don’t. I expect from you to be 100% focused on our team. We trust you to lead us to a better future while we trust your judgment and decision making. 

You are not a child; you cannot get it all

Dear product owner, part of your job is to prioritize the backlog to allow the team to deliver the most important stories first. But you are not a child, and you know that there is a reason why the prioritization starts with the top items first, and there is a reason why these stories are ordered (if not, we have a bigger problem than I thought).

The prioritization process is used to avoid a negative approach of "must" have. Remember that it’s the team’s responsibility to decide how many stories they can deliver during a sprint. Yes, their efforts are based on your prioritization. But once they decide that they can commit to only ten stories based on that prioritization, you cannot use the word "must" for stories exceeding this number. This will result in over-commitment and less focus that will most likely lead to poor deliverables. 

Know your boundaries and do not cross them

As the product owner of the team, you must ensure that the team has a clear definition of what they need to do to deliver the best product for the customer. Sometimes you forget the clear boundaries between you and the team, which will most likely influence team effectiveness, morale, and motivation. Now, what do I mean by this? Let's start with the basics: you are not supposed to interfere with the daily work of the team. I know that you probably think that you know better than the team just because 10 or 20 years ago you were a developer or a project manager chasing people to deliver what you asked of them.

It is NOT your job to interfere with team decisions on how to deliver what you asked. Your job is to prioritize the backlog to allow the team a clear definition of what you really want. While I expect you to be at the team’s daily scrum meetings, this meeting is for the team and not for you to control and interrupt. And above all, you are NOT the team manager who tracks their progress and asks them what they are doing in their day-to-day activities. You can gain this information by coming to the team’s daily meetings, reviewing the burndown chart, or just seeing the PBI state in the sprint backlog. In addition, while your participation in the team planning meeting is highly requested and most appreciated, you are NOT allowed to push the team to over-commit on work that they will most likely fail to deliver.

What is your vision?

Dear product owner, as a team member in your team I have enough going on without having a clue about why we are building the product the way you decided. I know you always say that the product backlog is enough to us to acquire this information, but there are 100 other teams that are working on the same projects, so I ask how we can understand the company vision without your help. Dear product owner, I expect to see a clear vision of the product. This will help us see the big picture and gain a sense of ownership over the product.

Knowing the importance of quality

Dear product owner, I know that you have a lot of pressure to deliver features to our customers. And yes, I also understand that this is how you can show how good you are by pushing the team to deliver faster while focusing only on getting more and more new features that will add value to the customer. But now you can see that quick deliverables that do not give real attention to quality are starting to affect our ability to deliver at the same pace we used to.

Dear product owner, can't you see that we invest a huge amount of time per sprint to fix quality issues that come from the field just because you thought that there is no room for investing in quality aspects such as test automation, unit tests or performance aspects of the application? These now come back to haunt us in the form of technical debt and bugs that consume most of our time. Dear product owner, I hope that you now become smart enough to understand that quality is a crucial part of what we are doing. I know that from now on you will allow us to create PBIs to will help us to create a better product that will allow us to increase quality and reduce future technical debt. 

With love,
Your team

Thanks to Tally Helfgott for proofreading :) 

Linkedin Profile

No comments:

Post a Comment

My Presentations