In an agile process, how much work should be done by the PO on a project or feature before presenting it to the team?

Question

In a recent 1 on 1 w/ my team’s product owner, we had a disagreement about how much work should be done on a project or feature before presenting it to the team.

The PO is used to creating specs up front as the starting point and presenting that to the team. Furthermore, he feels as though external (at least in our organization) resources, such as design, should be looped in and utilized during this period so the team can have a visual of what he is proposing.

I (the development manager on the team) feel differently. To me, the idea of the project/feature should be presented to the team at the earliest possible point. The PO would not have a spec, but instead, he would have an idea that can be clarified/documented via discussions w/ the team. I feel design also should be looped in as early as possible, but not prior to the team.

Answer 1

This comes down to appropriate level of detail.

The PO and Stakeholders will have a much longer term vision of the product than the scrum team. While an awareness is useful there's danger that the team start breaking down and designing work which won't be completed for a number of years (if at all).

Equally if the PO is going and designing all this functionality without knowing how much time will be required or how risky (if at all possible) a Story/Feature/Epic is then they're not making an informed decision when it comes to prioritising.

My suggestion would be to use your Backlog Refinement sessions to look into these. The team should spend some time making sure they understand the immediate work and getting it ready for the sprint. They should break down some of the mid-range work to a much smaller level of detail. Then they could do some basic story pointing of some of the POs long range features.

This would ensure they have an awareness of the features and have a chance to ask questions and offer feedback, it also ensures that the PO gets the information they need from the team.

The trick of course will be to make sure that you spend the right balance of time focusing on the right stories!

Answer 2

I think the PO is right. The spec and rough design, should be created before the team gets the task. Otherwise, how can you estimate the task?

However! This approach leads to the dev team becoming a 'shop' which churns out products to specification. Fine in theory, but in practice as you probably know, what is speced is not always the best solution.

Once you have produced something to spec, but not to need, a couple of times the PO will come around to your way of thinking and be asking "whats the quickest way we can achieve this" or "is there a good way to do that?" style questions before specing things out.

Of course this approach has downsides as well. It can lead to delays where tasks aren't fully clarified up front, hacky code where compromise solutions are reached and missed deadlines where extra requirements are only realised at the end of the project.

It's easy for a dev team to quickly produce code to spec. And aglie practices can work well for that. But the hard bit is knowing what the spec should be.

If the customer is writing the spec then to some extent you don't care if they get it right. But when the business is defining its own requirements everyone suffers the loss if a mistake is made.