ScrumMaster Tales – Waiting Too Long to Create Acceptance Criteria

This content is syndicated from Agile Pain Relief by Mark Levison. To view the original post in full, click here.

The recent Backlog Refinement session helped split the upcoming User Stories.

The team was able to get from a very large Story: “As a first time book buyer I want to read a trustworthy review before I buy a book” to:

  • As a first time book buyer I would like to read a review so I can see if a book is worth reading.
  • As a first time book buyer I would like to see a star rating associated with a review so I can quickly assess if the book is even worth thinking about.
  • As a first time book buyer I would like to see reviews by staff members marked separately so that I know whom to trust.
  • As a first time book buyer I would like to see reviews by friends highlighted so that I know whom to trust.
  • As a staff member I would like to write a book review so that I can help customers choose great books.
  • As a staff member I would like to rate a book I’ve reviewed so I can give customers a quick guide.

We’re in better shape than we have been with previous Sprint Planning meetings but the team lacks concrete acceptance criteria.


During the first half of a Planning meeting the team is trying to determine its goal for the Sprint. Specifically, it’s trying to answer the question, “What stories can we commit to?”  To have a realistic commitment the team needs small Stories and a clear understanding of what they will look like when they’re done.


Brad reads the first Story aloud, “As a first time book buyer I would like to read a review so I can see if a book is worth reading.” He sees an entire new web page, separate styling and a whole lot of infrastructure to support it. Doug, on the other hand, sees a small addition to each book page. He says that no new style sheets need to be developed. After a few more minutes of debate Product Owner Sue intervenes by saying that reviews will just live on the main page for now. In addition, each review must be under a thousand words and in plain text only.

Debate continues around each successive Story until two hours have passed; and the team is still unsure what they can commit to. ScrumMaster John has been doing his best to bring team members back to focus, but it’s been a struggle.


The team is struggling because they don’t have clear acceptance criteria. As a result, they don’t agree on the size and can’t agree on what to commit to. They’re spending the Planning meeting focusing on the question of, “What are we trying to do?” as opposed to, “What should we be doing?”

Acceptance Criteria (from a forthcoming Agile Atlas article):

The goals of Acceptance Criteria are:

  • To clarify what the team should build (in code and automated tests) before they start work.
  • To ensure everyone has a common understanding of the problem.
  • To help the team members know when the Story is complete.
  • To help verify the Story via automated tests.

Creating good acceptance criteria is a collaborative effort. Usually, they’re created by the Product Owner working with several other team members. When created in isolation they fail to meet the first two values.

In addition when we create them a few days before the Sprint Planning meeting, team members have time to consider just what they mean, how they fit the product and what is missing.

Let’s wind the clock back for the team to three days before our Sprint Planning meeting.


Sue asks Ian, Brad and Tonia to come spend half an hour with her. Their goal is to hammer out the acceptance criteria for each Story that might be committed for the next Sprint.

At the end of their white-boarding session they’ve got very rough sketches for the first three Stories that clearly limit their scope. In addition there are also textual criteria:

  • As a first time book buyer I would like to see a star rating associated with a review so I can quickly assess if the book is even worth thinking about.
    • Rating from 0 to 5
    • No ½ stars
    • It appears at the top of the review
  • As a first time book buyer I would like to see reviews by staff members marked separately so that I know whom to trust.
    • The word “Staff” appears in bold before the reviewer’s name.
    • All reviews posted from computers inside the Smallestonlinebookstore offices will be considered as staff reviews. (This avoids having to tag users as having different roles for now).

A few days later during the Sprint Planning meeting the team spends far less time debating and manages to get to commit to their Stories within the first hour vs. their traditional two or more hours.

When do you write your Acceptance Criteria?

Leave a Reply

What is 10 + 5 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”