I have be very vocally, internally in organisations and on blogs about the importance of the BPO role – as a member of an Agile team. A product owner normally sweeps around in 4 areas; Team Lead (sets the vision, and often the will of the team), Floor Walker (sets the expectations and stirs the feedback), Product manager (bread-and-butter prod man work) and Business Analyst.

Thats the hardskills – above all though they must employ the most important function, team member. Nothing takes priority over being there for you team. As the daily decision maker, as the point of domain expertise, as person to shoot ideas with. The rest all flows from here and the common point of failure is not because they are to busy to execute those tasks you list, but that they themselves have not been empowered to execute those tasks by the organisation.

What I mean by that is they have not been given full accountability for the product, so therefore cannot be responsible for the prioritisation. They are not trusted as domain experts, they role itself is not understood and committed to by the organisation.

For example – are you empowered as a BPO to make a decision and then explain it, or do you have to rally around for support on a decision and then ‘make’ it. That’s just one area where time (so … much … time… ) can be lost. As a BPO, let me make a decision and sack me for it later – if I have got it wrong.

Without that your BPOs are not empowered, as they cannot retrospectively examine their performance and improve. With it, comes BPO productivity and a body always ‘there for the team’ doing the bits of the Agile function that brings so much value when it is done the right way.

That said. I am busy

One of my Agile adoption clients has a single person as Product Owner. Another has a team. Both pull in people who know details, as needed.

Agile is more about principles than rules. What’s the simplest thing that could work? One person. Then you use observations from the daily stand-up, and iteration-end retrospectives (very important) to keep things real.

Product Owner doesn’t have time or knowledge to feed the team details for test cases? Usually not. Add subject-matter experts, as needed.

Other stakeholders don’t agree with Product Owner’s prioritization? Make their common supervisor the Product Owner, or pick a Governance pattern (I use the set from Weill and Ross’ wonderful “IT Governance” book) and form a Product Owner team.

Effective iteration-end retrospectives are your best friend. “Effective” means “changes something for the next iteration.” At least some of the time, you should choose to simplify something and see if it still works.

Maybe the Product Owner team can disband, leaving one person, because there were no arguments in their last two meetings, and they’re starting to complete one another’s sentences, correctly.

I often set up an Agile project with a facilitated stakeholder workshop to build the backlog, and then a smaller group (or one person) can manage it.

Both the world and the Scrum definition are flawed, but in my 5+ years of experience with Agile adoptions it’s a lot easier to ignore the Scrum definition and remain useful.

And as Adam and Craig get coding their bits of the elephant then you/controller/client get all that good feedback on how long tasks are taking and therefore how long the whole elephant will take to code.