The PO purgatory
PO’s are people who are the most crucial part in projects — and thus need some time for their job. PO’s are mostly but also involved in a lot of other stuff. So here’s an idea how it could work then.
Scare Time — Few inputs
This is sadly the reality. A PO in a project has not that many hours to work for your specific project. I always told customers it is a 50% job if you really want to do it correctly. And if you have all the other roles like ScrumMaster also defined and set. But in most times this is not reality. There are so more things to do for a PO — a good PO is involved in the organization, has contacts in company, is perhaps in a leading position — either line or subject and also is a social animal outside of the company ;-) so to say. So naturally his time for project work — defining features, ideas, valuing stuff, writing stories, epics asf — is not that well nurtured.
A shame, when you think of the PO as the person who is
a) committed to the project and
b) is a know-how bearer and
c) has overcome alread so many obstacles to start the project.
Reality kicks in. Nah — just joking. But really for the company because of the involvment in other stuff is too high big value is diminishing. But ok — that’s not our topic yet.
So this person is now more involved in internal stuff — but should support your project with input, ‘specifications’, ‘idea inputs’ and as mentioned writing down the features so developers can implement. But as mentioned above — there is no time for that.
Common rule?
The common rule is that the PO should have at least 30% of his job mainly committed to ‘requirements engineering’ — I would say with all other stuff for ideation, business analytics asf — the PO should have 50% as mentioned above.
Naturally a developer wants the PO to be the most as possible in the project — the best requirements and definitions of features, DOR, DOD and so on to creates super code.
But — the PO is himself all to be clear not mainly responsible for defining and writing down requirements. He is here to make it happen. So he needs to have a ‘crowd’ to make that happen. He is the guy giving ideas which are relevant. Looking at it — he is a filter for ideas, inputs and anything coming from ‘outwards’:
The product owner analyses, validates, grooms and valuates the requests and details it — either himself or together with others.
Coming out are epics and stories in a non-granular detail level. Then the work begins — creating the backlog in a such detailed level that the dev’s can work on it — err… estimate and then work on it when PO has prioritized as defined in the sprint start. Well — yes the stakeholders have their saying too but not in this phase. They are on together with the PO — finding new features, stories and stuff which could be useful.
So when the backlog has been defined more and thus is ready to be sprint-started then the PO is there to explain and discuss and give inputs.
So the PO has a lot to do. And definitely this is more than 30% — you already see it from here sitting on the tower so to say.
Why is then this number always in the head of people? Because in my opinion the PO is mostly still seen as a PM. Which he is not. He is not there just to control people, he is not there to just have an overview about the project. He is not there just to get insights into the financials and get a ‘hard grip’ on his team. The PO is there to enable the team to create amazing things, to help understand, to answer questions and to refine as well as to decide also sometimes to drop features. When the Scrum Master ist ‘Servant Leader’ then the PO is in my opinion a ‘Leader Servant’ — to lead the business view for the developers and to translate also a bit the manyfold requirements into understandeable and manageable bits. Together with the Scrum Master. The Team. And as well as with the stakeholders.
So his role is more than 30% . It is 70–80% at least. In my opinion this is mostly overseen in many companies. Also because PO’s are often seen as the ‘prolongation’ of the management on top or above. It is not. The PO is more than only a follow-up of management. The PO is more coach to management together with the Scrum Master than peer. The PO is in the role of an innovator, continuity manager, consultant, decider, leader, product developer, market insighter, analyzer, helper, idea feeder, filter, supporter and many more to the team.
So the PO is very important to the team. And as well as a Scrum Master can be a lead developer, a PO can never be part of the developer team in my view. Because the PO in it’s role should be clearly not taking part in implementations or technical decisions — alas, the PO can question decisions, yes and ask questions but should never take active part. Why not? Because his part is to be decisive on the business side, on the valuation side. And this is independant of technology and implementation.
— — — — — —
This is my opinion. What do you think? Is the PO so important? Or can the PO be part of the developer team?
