UK Site SA Site

Insights

Trends and insights making an impact in your digital transformation journey

What makes a good Product Owner?
Ronnie Cloete
Software development executive at DVT

What makes a good Product Owner?


A product owner is typically the project's key stakeholder. Part of the product owner's responsibilities is to have a vision of what he or she wishes to build and then to convey that vision to the scrum team. This is crucial to successfully start any agile software development project.


For the past nine months, I have been a product owner on a project and this is how it is playing out for me. But, before I get there, let's look at the real-life definition of the term.


A product owner is the stakeholder on a project who most likely has a day job but also needs to spend most of his week taking part in an agile project and all the ceremonies it brings along with it.


Based on my experience, a product owner needs an extremely clear vision of the intended outcome of the product being developed. They need to understand where the product fits in with the rest of the organisation and its related systems. Without that insight, your team will be developing a product that will not be used by the people intended to benefit from your product. It's that simple.


It is a very empowering position to be in and it should not be abused by enforcing your design ideas onto the product and the project teams. It is a collaborative effort in which everyone in the team has a say, but ultimately you know where the product is heading towards, which means the final decision-making power lies in your hands, and rightfully so. A product owner should be a servant leader where the team is empowered to deliver what you consider necessary without them wanting to exit. Therefore, ensure the team has a purpose and are working towards a common goal. Involve them in the project roadmap and the decision-making process.


How much time should you invest?

A product owner needs to manage their time adequately in order to be able to pay as much attention as required to the design and development lifecycle.


Here are the number of hours I spend on a project in order to steer a successful outcome at the end of a 2-week sprint.


Backlog Grooming 6 hours
Sprint Demo 2 hours
Sprint Planning 4 hours
Sprint Retrospective 1 hour
User Testing 4 hours


What does this mean?

It means I had to put aside at least 8 hours a week on an average sized project (4-6 members). If you are the owner of more than one product, those hours will multiply.


Being there for your team

Let's analyse a pile-up on a multi-lane highway and compare it to a product owner's role. The metro police (product owner) needs to make sure that the right decisions (backlog grooming) are made swiftly in order to avoid a traffic jam (development idle time). Whilst the rubble is being cleared (tasks in-progress) the metro police (product owner) also needs to reroute (feature prioritisation) motorists (agile dev team) in order for approaching traffic (future tasks) to know where to go so that they can reach their destination in the most effective way (adapting to requirements). In the absence of the metro police (product owner) traffic (work) will pile up and motorists (Agile dev team) will become annoyed at wasting time and not reaching their destination on time (delivery expectations). If there are queries and questions to be answered with regards to alternative routes (business rules and process changes), response time is key or else the motorists (agile dev team) will be held up instead of being able to cruise at 120kmh (continuous delivery).


Serving as a product owner is a very rewarding role especially once you see how an agile team operates to their full potential and your product comes to life.


Involve as many stakeholders as you deem fit to ensure product buy-in and at the end of the day be sure to allocate enough time in your working week to see a quality product rolled out.