Skip to main content

acceptance criteria

Last post 12:56 am May 12, 2021 by Chris Belknap
3 replies
07:27 pm May 11, 2021

Hello,

I have a question :)

The Product owners must create clear and unambiguous acceptance criteria for each item in the product's backlog before it can be selected in sprint planning, or can he create during planning?

I understand that acceptance criteria must be clear and unambiguous, but I think that don't need be before the sprint planning....because refinement can be done in the current sprint, right?

 

Tks


08:26 pm May 11, 2021

I understand that acceptance criteria must be clear and unambiguous, but I think that don't need be before the sprint planning....because refinement can be done in the current sprint, right?

The Scrum Guide says: Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.

Would those items be "ready" for Sprint Planning if their acceptance criteria were unclear or ambiguous? What do the Developers think about this? They're the ones who would have to do the work and commit to finishing it.


10:24 pm May 11, 2021

Acceptance Criteria is a nice to have in my opinion.  If the Product Owner has done a good job of conveying the reason and value of the Product Backlog Item, the Developers can usually gauge whether they have satisfied the reason.  With a team that is new to a specific product domain or to agile practices in general, acceptance criteria can be useful. But over time the Scrum Team forms a sort of "group think" that can make them less necessary.

@Ian Mitchell is correct that this should be a discussion that the Developers should have.  In some teams I've worked with they adopted the concept of a Definition of Ready that surfaces all of the conditions that need to be met in order for a Product Backlog Item to be considered eligible to be included in a Sprint.  It is not a Scrum artifact but it is an agile technique that has been used. 


12:56 am May 12, 2021

In addition to all of the comments I agree with above:

The Product owners must create clear and unambiguous acceptance criteria for each item in the product's backlog

  1. "Must" is a strong word. Acceptance Criteria is optional. It is not prescribed by Scrum, yet having said that it can be valuable. Everyone's context is different. Your mileage may vary.
  2. If the Developers feel it is valuable and a decision is made to use it, keep in mind the Product Owner may delegate this responsibility to the Developers.
  3. There's nothing to say it has to be written down - a conversation could happen as well (many refer to it an Amigos conversation).
  4. I see no reason why Acceptance Criteria couldn't be created in either Backlog Refinement or in Sprint Planning. It is typically created in Backlog Refinement, but if it needs to be there and has to be done in Sprint Planning then do it. There should not be gates to pulling work into a Sprint (i.e. an anti-pattern such as a definition of ready).

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.