Acceptance Criteria in Scrum

My opinion follows and while I respect your knowledge I find it useful to justify why/how I arrive at my opinions so I apologize if I sound a bit "preachy".  I hope that something I say is usable in the conversations you have with your organization. 

Acceptance criteria is something I find very useful although I am not a die hard supporter of the eXtreme Programming User Story format.  It sounds to me that your company is actually using that format as Acceptance Criteria was not part of the origin.  A.C. was adopted because users were finding it hard to know when the story requirements were met which was resulting in a lot of wasted work.  (Sounds pretty familiar doesn't it?).  Notice the inspect/adapt loop in User Story evolution (again sounds familiar doesn't it?)

I have always coached that a good story for the backlog will contain these elements:

• Who will benefit from the work (As a <user>)
• What change is in behavior is needed (I want to do )
• How the "who" actually benefits from the work (so that I am able to)
• How do you know that the work is done (Acceptance Criteria)

I believe in the information conveyed by the User Story format that are generally accepted but don't feel like it is always the best way to write up the information. 

Scrum IS an iterative process but it is supposed to be based on an joint understanding on what is work will be undertaken during the next time box before that time box begins. Things may be discovered that changes that understanding but that is the beauty of the iterative approach. It's goal is to help reduce/eliminate waste of effort in order to arrive at the correct solution for the stakeholders. The act of refinement is undertaken to add details, estimates and order to the Product Backlog. I honestly don't see how any kind of estimation can be done if the work request isn't fully understood.  Without some level of estimation and understanding it would be a miracle if something was done right the first time.  Take this out of software development and ask your company if they would accept this from a contractor renovating their master bathrooms at home. 

You are correct in how A.C. should be used in Scrum or Kanban or Scrumbut.  At least in my opinion you are.  How to handle it?  You will have to find ways to show how the absence of A.C. is causing waste and leading to unnecessary costs to the company.  It might also be good to show the waste is impacting the stakeholders.  Are they ok with the time it takes to deliver them value?  Maybe suggest that you experiment with providing A.C. for a set of Sprints to see if it improves the Development Team's ability to deliver potentially releasable increments. 

To finish I will say that there is no right answer to this. If the company for which you work feels that the way they are doing it is acceptable and they are not straying from the Scrum framework, then Scrum on.  But as a professional Scrum Master you can bet your a## I will be coaching "better ways of doing things" via "experiments".  

Good luck with this one.  Come back and share your experiences. It will help us and future readers learn from your work. 

The level of refinement needed in a backlog item is a balancing act. You can spend more time refining the definition of the work (which may include acceptance criteria), but that means it will be longer to get working and value adding software into the hands of stakeholders for validation. On the other hand, not having enough information to be reasonably confident in your delivery will mean that the software you deliver may be functional, but not necessarily valuable to the end user.

In Scrum, it's expected that the stakeholders have a shared understanding of what it means for work to be done in order to facilitate transparency. At a Product Increment level, this is found in the Definition of "Done". Acceptance Criteria are one way to gather a shared understanding of what it means for a particular backlog item to be done.

The best state is probably somewhere between "a smattering of an idea" and "clearly defined Acceptance Criteria". It depends on many factors.

The general consensus seems to be that if the business has a smattering of an idea, then the developers should build what they THINK the business is talking about, and then once it gets rejected we try it again.

At what point would the work be “ready” for Sprint Planning?

If the company doesn't really "need" clear acceptance criteria, how much discussion is now released upon delivery?

The short-version is that my company is under the impression that doing Scrum means we don't need to have clearly defined acceptance criteria for user stories. 

The general consensus seems to be that if the business has a smattering of an idea, then the developers should build what they THINK the business is talking about, and then once it gets rejected we try it again.  

Waste 101 :)

User stories are conversations on specific topics and should serve as value catalysts.

How would the management feel if they wanted to have a new office building built next to their current one? Would they really have no acceptance criteria? Wouldn't they want conversations with the constructors and align (both before the start of the construction, and also during it) so that the new office complies with the business needs, is of highest quality, etc, etc? Or would they just say "build us a new office"? :)

Use this precise example when you have a chance - see what they say

Hello everyone,

Thanks so much for your thoughtful, well-reasoned responses.  They helped clarify several things, and gave me some ideas on how to move forward.  I especially liked all of the metaphors that compared development work to construction.

SIDE NOTE:  Based on your suggestions, I asked one of my business users, "would you wait until someone moved into a house before you installed the electricity," because he wanted us to defer some necessary DB changes in order to speed up a UI development project.  And it worked!  He agreed to give us the requisite amount of time to do the implementation correctly.



Moving forward, I think I'm going to start documenting all of the wasted hours/ money that we lose due to development work starting prior to the A.C. being finalized/ signed-off on.  Then I'll present the report, and see what management says.



Thanks again,



Alex

@Alex - glad the other answers were helpful, but I wanted to add one more thing that I don't think was mentioned.

Does this product/team have a Product Owner? Based on your description, I get the impression that there isn't one or that he/she is not empowered by the organization.

According to the Scrum Guide, the PO's responsibility includes "Clearly expressing Product Backlog items" and "Ensuring the Development Team understands items in the Product Backlog to the level needed." Those are the standards that determine if and how to employ acceptance criteria.

When I hear that a development team is working with "the business" (or even conceiving of a separate group as such), it is usually indicative of insufficient communication/collaboration in the organization. In my experience, it means the development team is being forced "to identify what the product needs to be appropriate, competitive, and useful" (which, per the Guide, the PO is ultimately responsible for) by chasing down "the business" and begging for scraps of their precious time.

In Scrum, it is first and foremost the PO who will bear responsibility for waste and rework that reduces the value of the product, and therefore it is her/his incentive to make sure the development team understands PBIs and isn't just guessing. (Note: this does not rule out deliberate product experimentation!) Whether this is done with no acceptance criteria, minimal AC, or highly detailed AC is an empirical question outside the scope of the Scrum Guide.

(For what it's worth, I've worked with teams/products where AC was used as well as those where it wasn't used, or where it became wasteful. My overall opinion is that AC are usually helpful but have diminishing marginal returns, and that their appropriateness depends on each individual PBI.)