In an ideal world, there should be one Product Owner for one agile development team or squad. Or at a stretch, maybe one Product Owner for two teams, if they’re working on the same backlog.
At the moment, I’m not in that ideal world. My current project has five squads working on different epics, and only two Product Owners. We both have two full-time teams each, and we try our best to help support the fifth team between us that has no official P.O.
It’s a difficult situation, because we have to constantly context-switch between the work done between each team, and end up having lots of scrum meetings.
So how do we make it work?
Pick and choose the most important meetings
I find it impossible to make it to all of the various sprint meetings for three different teams – particularly when they all have the same cadence, and plan and retro on the same day as each other, often at the same time!
So it’s important for me to prioritise and pick the most important meetings to attend, and then trust in the team to be able to organise themselves without me at others.
I never miss the refinement. That’s the meeting where the Product Owner should take the lead and make sure that all stories are clearly understood and estimated. It’s also important for me to attend the sprint review/demo so that I can accept the completed stories on behalf of the business (even though I’ve seen the stories demoed before this meeting).
But other meeting can become more optional. In theory if I have the backlog well refined and prioritised, then the team can do Sprint Planning without me. They can take the most important stories from the top of the backlog, and match their estimates against capacity without my input.
Similarly I don’t feel like I have to go to all the Daily Stand-ups. I like to go to as many as possible, so that I can get a feel for the team’s progress, and help field any questions people have – but in a well-communicating team, we can have those conversations at any time of the day.
Concentrate on what’s most important
It’s easy to get into the pattern of hand-holding the development team through the entire requirements elicitation process. As a Product Owner I would normally hope to do all the heavy lifting in terms of liaising with stakeholders and working out all the detailed requirements.
However in a situation when I’m stretched, it’s probably more important that I set the general requirements for a story, and then maybe put the team in contact with a subject matter expert to thrash out the details.
It’s about letting go, and not getting bogged down in the detail of every story – and also in remembering that your team mates are professional engineers, and are more than capable of doing research themselves.
Faced with a number of conflicting needs, I find that as long as I deal with the most important things, then the rest will fall into place.
Ask for help from the team
Although the skill set is different between a Product Owner and the rest of the squad, there’s a lot to be said for asking the team to help out with traditional P.O. tasks when overloaded.
After all, that’s what agile teams are meant to do – they are meant to pitch in and help each other to get work over the line.
When I simply run out of hours in the day, I reach out to team members and ask them to help with my work – whether that’s writing up or breaking down stories, or adding acceptance criteria, or maybe taking the lead in a meeting that I can’t attend.
It’s amazing how people are so willing to help out once you ask them!
Don’t get drawn into things outside your role
I’m often invited to meetings that are not important for me. I don’t need to be in the tech sync, because I don’t understand half of the stuff they’re talking about anyway. I don’t need to join the sales call, because it’s not important for me to listen to news about sales leads.
Some people want to be involved in every meeting because they want to know about everything that’s going on. But I prefer to leave the Project Management updates to the PMOs, and technical discussions to our Tech Leads and Architects. I don’t feel the need to be in every conversation. Instead I prefer to concentrate on the things that will help me out the most, or where I can deliver the most value.
In my company we recently moved towards the Spotify model for our agile squads, which does away with the Scrum Master roll. The idea is that the duties of the scrum master are absorbed within the team itself – with either one person taking it on part-time, or it rotating within the team every couple of sprints or quarter.
When we made this change, I know that there was a feeling from some people that it would be easiest just to get the Product Owners to take on the Scrum Master activities – something that I vigorously pushed back against. I’ve written before about the time I was both Product Owner and Scrum Master, and it was a challenge then when I just had one team to look after.
Ask for more Product Owners
So, for the moment, the two of us are getting by with looking after the five development squads. But at the same time, we’ve also made it perfectly clear that we need more Product Owners to relieve the strain. It’s not sustainable in the long run.
And the good news is that it seems that there are two additional Product Owners lined up to join our project, which will be great when it happens. It might take a couple of months before we get them, and it might take a similar amount of time to get them up to speed, but at least we can see an end-point in the future when the pressure will be relieved.