Agile Software Development

How an Empowered Product Owner Can Avoid Being Buried

In an article for Scrum Alliance, Dele Oluwole identifies empowerment, change, and continuous improvement as three core aspects of agile software development. He finds that the significance of empowerment, especially as it applies to product owners, has been understated though. Empowerment is a slippery slope, and it fundamentally affects the project bottom line.

Power and Vision

Product owners must have the power to ensure business value is created, yet they must not be so powerful that they end up disconnecting from others and defeat the purpose of their role. It is not unforeseeable though that product owners could get so caught up in working with the development team that they neglect to maintain regular contact with stakeholders. Oluwole remembers a time where a product owner and business analyst jived so well with a team that they basically become just more developers on the team, which incurred the effect that the product starting going off track. The team fortunately recognized its mistake, took responsibility without blaming the product owner, and got back on track.

In order to avoid such situations, Oluwole recommends product owners do four things regularly: create a traceability matrix for business requirements, hold product demos, schedule catch-ups with stakeholders and/or users, and recognize that the product backlog is always owned by the product owner. About that first tip, he elaborates with this:

This is very important, as it’s easy to mix together the requirements, use cases, and user stories and forget to link them to features and values driven by the business. The PO and business analyst must work together to ensure that there is a traceability matrix so that requirements are linked to test cases, development tasks, and the final features when done.

Product owners have a great deal of control as far as flat teams go. They need to use that power well, since as Oluwole notes, flexibility is how risk is managed in agile. It cannot rely on structure to manage risk the way it is in waterfall.

You can view the original article here:

Show More

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.