Are you a Product Owner? Let me ask you few questions.
When did you for the last time publish your product to end-users and when did you gather feedback from them?
yesterday? week ago? month? quarter? half a year?
It is the core of the Empiricism – validate our assumptions and change behaviour according to the results received. It is the first question that I ask the Product Owner. For me, it is a great discussion starter regarding the agility of the product, the team and its environment. And I do not even need to start such conversation because my interlocutor normally has a gut feeling that it should be more frequently and he starts to give arguments (or excuses), why it is as it is.
In reality, no one wants to come back to times of waterfall when we had no information from the market if our idea is right or wrong. We had to make all decisions based on assumptions without clashing them with real life.
So why are we still building products “the old way”?
The Product Owner’s main point of interest
Clearly expressing Product Backlog items;
Product Owner’s responsibilities – Scrum Guide
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; and,
Ensuring the Development Team understands items in the Product Backlog to the level needed.
If you look at Product Owner’s role in Scrum Guide (above), you will notice one thing – Product Backlog is the main area of the Product Owner’s interest. It is his responsibility. Sounds easy, but is it?
As long as we develop and improve our product, Product Backlog is never complete nor finished. It may look like your (as the Product Owner) work put into Product Backlog is just a waste of time, that the time of the Development Team spent into refining next ideas may be better used. Don’t be wrong! Product Backlog is the single source of truth for a whole Scrum Team and everyone around it.
Product Owner is responsible for the Product Backlog, but he shouldn’t work on the Product Backlog alone. It may lead him to plenty of false assumptions. He may use a whole organisation, stakeholders, clients, users, but most importantly – Product Owner has a whole Scrum Team to use!
Scrum gives more help for Product Owner than just the Product Backlog. It gives you a frame built on the Empiricism and Scrum Value. And on Scrum Values I wanted to elaborate a little bit more.
Scrum Values in Product Owner’s job
Scrum Values are always presented as something which should:
- drive the Development Team’s actions;
- be groomed by Scrum Master.
They are very rarely presented from the Product Owner’s position. I would like to change it and show, how Scrum Values may impact Product Owner’s day-to-day work.
Focus
Product Owner should focus on the work performed by the Scrum Team daily. He should be available for the Scrum Team whenever needed. Development Team should be able to come to the Product Owner and ask questions regarding PBI’s details. A whole team should see that Product Backlog is alive. Without that, the Development Team may lose focus on what is important and just “do stuff”… and it may not end up well.
The same as Development Team has their job to do, Product Owner should focus on his – and his main job is the Product Backlog and work related to it: clarification, ordering, adding new ideas, removing worthless PBIs, gathering information from stakeholders, analysing feedback from users and putting it into Product Backlog…
Product Owner is always on the meetings. Development Team last time saw him on the Planning… or worse – on Refinement, where they prepared ideas for next sprint and that “next sprint” is already in progress… this cannot work!
Respect
Mutual respect. Agile is based on the idea: the right people make the right decisions.
This means the Development Team decides:
- how to implement the Product Owner’s vision. Product Backlog should focus on possible benefits and advantages, which Product Owner wants to achieve and on the direction in which he wants to develop the product and not on the small bits of a whole process. Outcomes – not outputs.
- how much work is needed to complete the work – it does not matter if the Development Team estimates in hours or story points. It is still their responsibility to estimate PBIs. Do not take it from them.
- what they can finish within a Sprint – do not put too much pressure on them. Product Owner works within the same team – just a different role. They respect Product Owner, so he should respect them and their decisions.
- who should perform specific work – it is their responsibility to transform PBIs in working product. Product Owner should not assign tasks to the Development team’s members.
It does not mean the Product Owner shouldn’t ask questions and to expect honest answers. If he does not understand the reason why the Development Team has made a decision, he should ask. The same as any other Scrum Team member. Remember one of the Agile Manifesto’s principles: Collaboration between the business stakeholders and developers throughout the project.
Commitment
Start building commitment from yourself
my manager from the past
I believe it is a powerful statement, but very true at the same time. Normally we require commitment from the Development Team, and sometimes we forget the same from management positions. Within the Scrum Team, we have two – Product Owners and Scrum Master.
Product Backlog Items prepared for Scrum Events is the best evidence of the Product Owner’s commitment. Having smooth Planning and Refinement is the best proof of the Product Owner’s and Scrum Master’s collaboration.
Development Team’s motivation is strongly connected with their belief in the work they perform. If they do not know, what to do or if they do not feel that Product Owner knows, where they are heading, they may not be engaged fully into it.
Most importantly – Product Owner, who goes to his job with enthusiasm and who has a clear vision, gives a strong urge to finish any topic successfully to the whole Scrum Team (Done-Done). Product Owner who is passionate about his job – this is a powerful motivator.
Courage
The Scrum Team is often under extreme pressure – especially when Scrum is a new and not-known approach in the organisation. The Management pushes on the development of new features in the middle of Sprint. Other teams involve team members in different work, and somebody else tries to change the release date to “speed things up”.
Product Owner has to have the courage to stick to his responsibility and agreed Scrum process. Scrum Master is his biggest ally in this uneven fight. Stakeholder’s analysis, Risk analysis, setting goals to the product and expectations towards it, help in progress tracking against the plan daily and in the long run. These are only a few elements, where Scrum Master’s help may be required. Product Owner needs to have the courage to ask for it and to accept it when proposed.
Do you know everything? Do you know what your clients require before he even thinks about it? No? Great! There are more people like you around! Thanks to Empiricism, you can validate your assumptions and say “I was wrong!”. It is better now than after spending millions $ on not-needed-features.
Every Product Owner has to have the courage to take a risk and to say “no”. Only thanks to these, you may create great results.
Openness
Openness is crucial in the Product Owner’s work. Product Owner has to be open for feedback – in giving and receiving. The best source of feedback is the working product and its users. Remember: you will know the real value of your product only when you give it to the users. Without that, you only have assumptions.
Product Owner should know how to give honest feedback to developers. He is the first “client” of their work. The Development Team may improve thanks to information from him and to give better results next time. Faster feedback – faster change – faster improvement.
Engaged Development Team will also look for the best way to perform their job. Having honest data may help him to choose the right path.
Product Owner should also listen to the team. If they have a different way of working or they came up with a new idea – The Product Owner should be open for new solutions. He should also remember about validating them via proper acceptance criteria. Without that, he will never know, if it was worth trying.
Empirical process
Do not look at the Scrum as something new. Look at it as on the experimental process or even better – PDCA cycle popularised by William Edwards Deming in 1959. PDCA cycle is a continuous quality improvement model built from four steps: Plan – Do – Check (Study) – Act, and it greatly summarises the idea behind whole Empiricism. Scrum looks at the Deming Cycle from two dimensions – Process and Product, so there are two cycles that overlap.
Work with Product Backlog is the empirical process. Only based on performed experiments and by validating results from real-world, the Product Owner can create a great product. At the right moment, when you resign from your real-life feedback loops, you lose a wast majority of Scrum’s benefits.
Takeaways for all Product Owners
As a takeaway from this article, I would like to give you a few hints to follow. They are as important for Product Owner as for any other Scrum role so use them wisely.
Collaborate with the team – because you have a common goal and you share the same problems. This is something that helps to become stronger every day.
Use advantages from Scrum – the ability to experiment, fail quick and to change directions is the biggest benefit from Scrum usage. Do not underestimate it!
Every element of Scrum matters – they are put there on purpose. At first, they may look like a waste – but they greatly highlight any problem. Thanks to this – you can fix them and improve!
Scrum Values are not only empty slogans – they matter. Keeping them in heart let you collaborate with others and improve the outcome of your work.
Everything starts from Empiricism – transparency, inspection and adaptation. You do not need anything else to succeed.
But most importantly – Look at the value!
References
- Every Great Product Owner Needs a Great ScrumMaster – Roman Pichler
- 6 Ways a Product Owner Should Collaborate With Their Scrum Master – Kreisler Ng
- Coaching Your Product Owner As A Scrum Master – Jeremy Jarrell
- Six signs of a successful Scrum Team: The Product Owner primer – Nick Butler
Pictures used in this article come from AgileMe website.
