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.

  • 1
    In addition to my answer - have you asked the team, openly (perhaps in a retro) which bits of the specs they find valuable and which they skim over? Maybe you could "reduce the POs workload" by streamling and only asking them to write what the team need? – Liath Mar 15 '18 at 9:41
  • 2
    The main idea of "agile", to my understanding, is to adapt these process details to the specific feature and the specific persons involved. Some features deserve a spec up front, others not. Some developers want to be treated more as coders and expect to get a detailed spec for every story, others don't. So there is no "one-size-fits-all" answer to your question. – Doc Brown Mar 15 '18 at 10:17
  • My plan (thanks to all of your ideas) is to discuss this with the team. I have opened up my thinking on this concept. I agree that this should be brought to the team and how much "prework" is done is best determined by the team on a case-by-case basis. As with most agile issues, it seems this really comes down to better communication. – Zach McKinnon Mar 15 '18 at 14:41
  • If the designers are an external resource for you, I would def agree to have those pieces done as much as possible before they enter your workflow & process. – Graham Mar 15 '18 at 15:04
  • Customer provides the what via desirements. Elaboration is dependent on framework, system, context, etc. Product Owner provides the when via prioritization. Development Team determines the how via design and implementation. – Alan Larimer Mar 19 '18 at 17:43

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!


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.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.