The Product Owner’s tasks according to the Dev Team

One of the questions that inspired is: “What do you expect of a PO? What are her tasks?”

As always, the answer is “It depends”. One major influence on what I expect from a PO is maturity. Not the PO’s, the Dev Team’s.

A team that’s recently started using Scrum usually expects a user story to come with a subset of the following:

  1. detailed description
    • sometimes with a specific solution
  2. further details as acceptance criteria
  3. list of test cases
  4. Photoshop mockups of all interfaces
  5. everything clarified with stakeholders

Can you feel the remnants of a compartmentalized, planning-heavy process?
Yet, I wouldn’t try to shake all of the habits right away. A PO trying to share those duties with the team rightaway will often be seen as not doing her job. “That’s what YOU’re here for, aren’t you? Do we have to do your job, too?”
Heaven forbid that the dev team have to clarify details with a marketing guy themselves…

The trick is for everyone to slowly evolve from “everything’s pre-chewed” to “we can and want to do this together – results will be better”.

A PO that fulfills none of the above can actually be a great PO – to a mature team. Much better than one who stifles the team’s creativity by over-specifying everything:

  1. A detailed description is dangerous as it gives the illusion of understanding. The conversation might not take place.
    • Within a Scrum team you can often come up with several possible solutions. Don’t limit your solution space prematurely to just one
  2. Record ACs when they surface during Grooming or Planning
  3. Test cases are the same case as ACs. PO and dev team come up with these together
  4. Photoshop mockups are useful for new applications. Once a team has built similar features it can often reuse design from existing features and only needs a wireframe mockup. They may even come up with the the interaction themselves
  5. Talking to someone outside the team directly, avoids the Telephone / Chinese Whisper effect

The PO can spend the freed up time very beneficially:

  • prepare design studios
  • analyze the market
  • research ROI implications
  • speak to customers
    • expose the dev team to customers
  • champion the product

The shift from pre-chewed to shared is gradual and takes about a year. In my experience at least.

Stefan Roock makes a similar observation, judging from how the Definition of Ready tends to shrink over time.

What observations have you made?