Should the customers or Product Owner worry about making all the acceptance criteria known in advance? Or should the Development Team and Scrum Master worry about them?

I'd suppose that it is the responsibility of the customers to exactly express all the acceptance criteria. If they failed to do so, then it is their fault (not the Team's).

5 Answers 5


Scrum is based on an empirical process control system. It assumes that not everything is known and that knowledge will emerge over time. Trying to specify every acceptance criteria in exact detail may not be possible and may take way more time than needed.

It's not possible to know all acceptance criteria in advance.

Instead, Scrum explains that the Development Team has continuous contact with the Product Owner or Customer to receive feedback. Additional Acceptance Criteria and adjustments to previously written acceptance criteria can emerge during the sprint as part of over-the shoulder-reviews, short demos, proof-of-concepts early in the sprint or even wireframes or paper prototypes. The development team can accept these additional and adjusted acceptance criteria and work them into the increment immediately, or, if the work would be major or endanger the Sprint Goal, the Product Owner can choose to put the additional work on the Product Backlog for a future sprint.

Another opportunity to inspect the Increment happens at the Sprint Review. The Customer can inspect the Increment and provide feedback in the form of new and adjusted Product Backlog Items.

The aim of Scrum isn't to deliver everything first-time-right. It's to deliver things quickly and provide opportunities for feedback. This feedback will allow everyone to further refine the product and mold it into the product that is truly needed, not the one we had described on paper.

Who is ultimately responsible?

The Product Owner remains responsible for defining the What and the Why. They remain accountable for the functional acceptance criteria and the required non-functional characteristics of the product.

The Development Team remains responsible for defining the How and the Quality. They remain accountable for the technical acceptance criteria and to turn the non-functional characteristics of the product into technical solutions that meet these characteristics.

The Scrum Master has no accountability on content, only on the process. Therefore they play no part in this. Unless the process to get the requirements and to receive feedback is broken in your organisation. If that is the case, the Scrum Master should help remedy this situation.

Dealing with the impact on estimates

This question often surfaces, but how to deal with our estimates? If we accept that we can't know everything all the time, we should also accept our estimates will be less accurate.

Interestingly, if we tend to find the same number of unknown acceptance criteria in every sprint, then their impact will become evident through a lower velocity without ever having to adjust the way we estimate.

  • I don't think it's safe to say that the Product Owner is responsible for "functional acceptance criteria". There are also non-functional characteristics that come from external stakeholders that may arrive through the Product Owner - disaster recovery, security, performance, availability and uptime are a few examples. How these are met, though, are up to the Development Team.
    – Thomas Owens
    Commented Dec 28, 2019 at 16:04
  • @ThomasOwens, you're right. And I'd want the PO/Stakeholders to describe what they need from the system. Then the Development team to transform that into technical requirements. The customer needs availability and security. But how to meet these are ideally selected by the Development Team. Too many Product Backlogs contain all kinds of technical details which the team can fill in for themselves. It does require a mature development team. Commented Dec 28, 2019 at 16:15
  • The availability, security and performance could be covered under the Quality Standards ad referenced from the Definition of Done, in which case, the Product Owner wouldn't need to be concerned too much about them. NOT having defined the technical aspects by the Product Owner, does keep the responsibility for these aspects with the Development Team. Commented Dec 28, 2019 at 16:20

If the quality of the product isn't good, is the Scrum Team fault

It is never the stakeholder fault!

According to the Scrum Guide (2019), the Scrum Reviews are "informal meetings" in which the stakeholders are invited to participate and collaborate. Being "informal meetings" we expect the requests, needs and ideas presented by the stakeholders to be informal. The stakeholders inputs are very important, but those requests, needs and ideas are only inspiration for the team to identify what can add value for the product.

A superficial look in the Scrum Guide may give the impression its the Product Owner fault, but it really isn't

"The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog includes: Clearly expressing Product Backlog items" (Scrum Guide; 2019)

From that perspective the responsibility of the Product Owner alone.

The responsibility is shared by the whole Scrum Team

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. (Scrum Guide; 2019)

I think the Scrum Guide is clear enough: The Development Team always shares the accountability on incomplete backlog items.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable (Scrum Guide; 2019)

I think is no coincidence that the Scrum Guide emphasize that the Project Owner can rely on the Development Team to organize the backlog. In my experience this is the most common practice. As consequence, the Development Team share the accountability.

The pointing fingers game is very dangerous

In the end, if the Scrum Team members begin the pointing fingers game, the backlog will become a contract and the team will loose its dynamic and fail.


Why are you talking about blame?

Your Question reads, to me, like "Something went wrong. Who do we blame?" The only situation in which "responsibility" (read: blame) should be relevant is when it is necessary - namely, when selling to an external party. In which case, the only valid answer could ever be: "Check your contract". This is a question for a lawyer, not a project manager.

Ideally, it doesn't matter.

If you're working with an internal customer, then what does it matter? So you reached the end of an increment and the customer pointed out something that wasn't done as s/he wanted? Good. Now you know what to work on next. Move on.

If you absolutely must know...

As per a quick ctrl-f for 'responsible' in the Scrum Guide...

The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. [...] The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

  • Time spent on implementing something different from what was expected is a lost time and lost money. This is important. That is why I asked. Thank you! Commented Dec 31, 2019 at 15:41
  • It also forces us to review and possibly change estimates and release dates. Commented Dec 31, 2019 at 16:31

The product owner is responsible for defining all the items in the backlog with enough detail for the team to be able to work on them. Acceptance criteria is part of those details. The product owner needs to have these clearly expressed before work begins.

Of course it's also the team's responsibility to make an effort to understand the items from the backlog to the necessary level. If they have questions, need more details, etc, they need to raise them with the Product Owner.

It is also the Scrum Master's job to make sure people collaborate and communicate to the proper level needed.

Ultimately though, it is the Product Owner that remains accountable for having items properly defined, acceptance criteria and all.

And since nobody is perfect, if something occurs and some things remain unclear, or some acceptance criteria is forgotten or omitted, this is an opportunity to improve your practices, not to place fault. Try to find better ways to work together, not point fingers.


Have a customer or product owner to worry about making all the acceptance criteria known in advance?

We shouldn't expect the customer and Product Owner to get requirements perfectly right every time. The reasons for this are:

  • It is very difficult to think of everything when defining a requirement
  • Excessive time spent defining requirements is a form of waste - at some point it makes more sense to start development rather than continually refining the requirements
  • Most development has an element of discovery, where new things are revealed as the work is being done
  • Feedback is one of the best ways to refine requirements and you don't usually get feedback until you start development

Or have a team and scrum master to worry about them?

The Scrum Master and the development team should be focusing on the process that they are using to discover acceptance criteria. If they recognise that important acceptance criteria are being missed then they should raise this at a retrospective so that the problem gets addressed.

I'd suppose that it is the responsibility of a customer to exactly express all the acceptance criteria. If they failed to do so, then it is their fault (not the team's).

One of the Agile values is customer collaboration over contract negotiation. Rather than looking to assign blame it is usually more productive to concentrate on improving the way things are done.

Perhaps by working collaboratively with the customer you can find a way to reduce or eliminate the problems you are facing?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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