At Enrise we started ‘Scrumming’ in 2011. Since that time we experienced quite some different interpretations and expectations of Scrum. We often had to explain to a customer that they don’t just bring a bag of money and have to wait and see what can be delivered until the bag is empty. Quite often we also need to explain the opposite; Scrum isn’t the Holy Grail, it won’t go automagically. It also isn’t cheaper, finished in a week or guarantees better quality. Proper management, a clear vision, preparation, processes and risk management are all still necessary.
Through the years we have learned how to cope with all these different interpretations. We noticed that Scrum has become a more familiar term for customers. A lot of our customers even started Scrum development themselves. These companies implement Scrum in their existing teams which unfortunately result in not having their own dedicated Product Owner or Scrum Master. Nowadays we have to cope with the diverse expectations and interpretations, especially regarding the roles in Scrum, mainly focusing on the one of product owner.
The product owner role
The definition of the product owner role according the Scrum guide is:
The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. The Product Owner is the sole person responsible for managing the Product Backlog.
In my experience and opinion the Product Owner role includes a lot more than this. A Product Owner must create a shared vision, manage expectations, make sometimes unpopular decisions without insulting someone, translate every idea that someone throws at you so the team can develop it, prioritise the features to be build, help making (technical) choices, make it to deadlines, stay in budget, etc.
Everyone expects the Product Owner to build the perfect product, delivering maximal value, taking the future into account and do all this as cheap and as fast as possible. There is not a single person who tells the Product Owner how to do all this and neither does the Scrum Guide.
I am Product Owner for a few years now and it is a difficult and complex role. A job that is often under-estimated proven by the variety of people fulfilling this role often besides their regular full-time job. Most Product Owners, including myself, do not master all these skills, but I have encountered quite some pitfalls which make me a better Product Owner and hopefully can help you to become a better one too!
Manage the Product Owner pitfalls
Scrum’s image (or any Agile method) is that a planning isn’t needed. Just take it one sprint at a time and let’s see where we end up. Nonsense of course! Stakeholders will start asking you when ‘it’ will be finished or what ‘it’ will cost. Off course they will! Customers need to be managed, the product must be sold, campaigns will start, budgets aren’t infinite and more of these reasons.
A Product Owner needs to make sure they can give always an answer, except an ‘I don’t know’. In order to be able to do this:
- You need to focus on the next few months instead of the next one or two sprints;
- You need to create stories or epics roughly describing the features for these months, so you can share these with your team in refinement sessions (which will also help them make the right technical decisions in the current sprint);
- Let your team give an estimate, in a magic estimation session for example, so you can use this in a release planning or burn up chart.
You still won’t be able to give an exact answer to all the questions you get, but you will be able to predict something.
Some people will say that this looks like waterfall but that’s not true. Taking months to write a plan and execute it literally is something else then creating a vision and review every few weeks what has been build, gain new insights and possibly change the course.
Looking ahead will give you control and will also enable you to make decisions.
For example postponing a deadline or skip a few stories/features to make a deadline or take a shortcut in the software (to be able to quickly ship a feature, so actually create technical debt by choice), etcetera.
Speaking about technical debt; be very careful with that! Technical debt can’t be prevented. You have to deal with it, but it’s like a loan with (exponential) interest. The longer you wait to reduce it, the more it will cost until it eventually is impossible to do and you have a product that is unmaintainable and can’t be extended with new features.
Build the right stuff
Everything you decide to add or change to the product should be in line with the product vision and the goals which you have defined on your Goal Oriented Roadmap. But what does this mean exactly?
This means that:
- You will have to learn to say no;
- You must stick to your role;
- You must be SMART (pain/gain);
- You must own it!
Everyone will have an opinion about the product your team is building. Many stakeholders will have ideas about improving or extending the product. Which is a good thing off course, because you want people to be enthusiastic and try to help improving the product. But don’t put every idea or suggestion on the backlog just to please them or prevent disappointment. Saying yes to everything and everyone is easy, but when you say yes all the time then your backlog will grow exponentially. It will take longer and longer for features to be delivered or they won’t be delivered at all because the priority changes, for example due to changing insights or markets.
Eventually people will still be disappointed and they will blame you for it. So control your backlog and dare to say no to some ideas and explain to these people why you are saying no and try to create understanding.
Stick to your role
You are responsible for the product that is built, not the way it is built. Often Product Owners focus too much on the process and try to make the team as efficient as possible and get value as soon as possible. The result is that you will have a team that is happy and everything is running smoothly, which is a good thing, but the risk is that they are building the wrong thing.
Make sure the team is working on the right features, not that they are building it right, that’s their responsibility.
A Product Owner must determine what is built and in what order it is built in. Stories need to be prioritized the SMART way: Specific, Measurable, Assignable, Realistic and Time-related. You can’t prioritize stories based on people’s wishes because managers, customers or other stakeholders all have their own preferences and priorities.
You need to have measurable numbers to make a good decision. You need to know what it will (approximately) cost to build the feature and what the added value will be.
If something adds a lot of value and doesn’t cost too much to build you will want to give this higher priority instead of something that will cost more with less value.
Scrum will tell you that the most important thing for the Product Owner role is mandate. In real life this is more sophisticated; there are Product Owners in big traditional organizations but also on the supplier’s side and sometimes the Product Owner is an external (freelancer). These are all different situations that have their own complexity.
In every situation you need to claim ownership, not by yelling at everyone that you are Product Owner so you decide, but by doing the right stuff, share information with stakeholders, creating understanding and more. Then people will listen to what you say and trust you to do the right thing.
Don’t be chicken!
As a Product Owner it’s not enough to be involved, you really need to be part of the team. Don’t be that guy that drops some work every two weeks. Because in those situations, at the end of the sprint the Product Owner will ask all kinds of questions that wouldn’t need asking if he would have been part of the team and be committed to and experienced the sprint himself. The developers will start to defend themselves and soon it is a ‘they vs us’ situation instead of ‘we together’.
The Product Owner and team must trust each other and this can only be done if:
- You do it together, one for all, all for one
- Equivalent approach
- Asking the right questions
One for all, all for one
Developing products using Scrum is a team effort, just like it is in rugby, where the verb is coming from. You need to have trust that everyone is playing their part in the whole, taking their responsibility and that they all do their best. You need to be willing to ‘take one for the team’ and help team members that need support. If one person in the team is having trouble with their part then the whole team, the sprint and the product, is in trouble.
A Product Owner doesn’t rank higher than any other team member, you just have a different part in the whole. You must be part of the sprint, attend to the standup, hear what is going on, so you can help the team for example by removing something from the sprint or doing things different.
Also share with the team what you are doing. That gives the team context, so they have better understanding of the difficulties you are dealing with, enabling them to make better decisions and help you.
Ask the right questions
Almost psychological but not less important; respect and accept what team members are telling you. Do not doubt them, they have their own responsibilities and expertise. Don’t ask if the estimate is accurate. Don’t ask about the difficulty of the chosen solution. Don’t ask to be faster in less time. Instead of asking explain the problem you are experiencing and try to see if there are alternatives.
With these experiences I gave you some insights in the practical part of being a Product Owner. Through the years I have learned a lot about what the Product Owner role really is. For me it is a difficult but beautiful role when played the right way.