The Product Owner Role

When thinking about product owner tasks, the creation of user stories and backlog maintenance are always identified as the most important things that a product manager/owner delivers to their development teams. But the role of a product owner (PO) involves much more than the simple translation between business requirements and a well-known-everyone-accepted user stories template. If you want to get an overview on how we do it here in Mindera, keep reading.

User stories gathering and MVP roadmap definition

Our projects, usually, start with a Sprint 0. The Sprint 0 is a more than one day intense meeting, where a multidisciplinary team of developers, product owner and designers, get together with the client to discuss the project requirements (functional and non-functional) and to depict them in Epics and Stories. The multidisciplinarity of the team available during this sprint is of paramount importance, mainly because each person, with their different background and knowledge, gives different perspectives on how to better answer the client requests. Following an MVP approach, by the end of the Sprint we a have set of stories (in different levels of definition, from fully to roughly described) together with some application mockups/layouts.

Sprint 0 also delivers an overall roadmap that will guide, from a high-level perspective, the project execution. By the end of the sprint (e.g. a three day meeting), the project team can just start working directly in the project stories. So, there is no project slow start and the team is engaged, working, and delivering since the very first minute.

User stories and the development team

Bad user stories have a strong negative impact on the development team, they are the cause of endless friction and misunderstanding on the customer and, more than less, result in missed deadlines and/or sprints.

We like to think that developers are great problem solvers, instead of order-takers, checking off a list of specific requirements. If you follow this idea, then user stories are the trigger to start open discussions around user, business, or technical requirements. Open discussions give the chance for individuals to elaborate and collaborate on the user story definition, while, at the same time, establishing a trusts and empowerment relationship between the PO and the dev team. So, the rejection of the command and control model and the open discussion concept gives us the opportunity to discuss the user stories from different points of view (each individual bringing his/her own experience), which hugely reduces the chance for a bad user story definition. When we start a development cycle we are sure that the entire team is aware of the problems we are solving, along with the possible risks that may appear during the journey — we are all empowered and share responsibility!

Roadmaps, development cycles and the development team

If you’ve read this far then you know already that the development team is as much as possible aware of the user stories and aware of the business — team members were involved on the user stories discussion. Developers have a clear idea of the overall product we, as a team, are developing. As the PO you define the stories that should be included in each development cycle and the roadmap, right? Wrong! You don’t define, you propose, discuss, and negotiate! And there is a huge different in this. And what if there is an imperative, impossible to move ahead the business reason? Then the PO starts a discussion as open as possible about the stories that need to be included, explaining the reasons and the plan. If a trusting relationship is in place, the entire team will understand, engage, and help on how to overcome any roadblocks, otherwise you will have people doing tasks just because someone ordered to.

Of course, as a PO, you always have the responsibility to keep the backlog as organized as possible and to structure the stories into epics and themes so they directly and clearly relate to clients expectations and team availability. It is under the PO responsibility to organise things but not to decide or enforce.

Note: it doesn’t matter what agile management framework you play with (from kanban to scrum) we really believe that by putting people as the core of all your actions, we get better results, customer recognition, and, in the end, happier people ;)

Keep tuned!