Over the past few Sprints, we’ve found that many of the stories we’re trying to estimate or prioritize need more information. Of course, much of the details behind each story should come out during the Planning Session (which we hold the day after the Grooming Session). But, since we are trying to get through many stories at once, we usually don’t realize, until it’s too late, that we’re missing key information.

So, lately, we’ve been trying a fast-paced ‘User Story Workshop’ or ‘Story Time’ every Monday after our Morning Standups to avoid this. That’s 9 days before Grooming.

The process goes like this: every other Monday, we stay after Standup, and, while still milling around a big whiteboard (you can sit if you want), we list out the User Story, Acceptance Criteria (AC), and ‘Doneness Criteria” (Done) definitions on 3 rows, as pictured above.

The User Story is what the user wants in a simple statement. The Product Owner usually provides this. The Acceptance Criteria, or ‘AC’, is stated by the Product Owner as what he or she wants to see when the team demos the completed story at the end of the sprint. The “Doneness Criteria,”  or “What’s Done?,” are the behind-the-scenes criteria the story needs to meet before the rest of the team believes it’s a quality deliverable (speed, what servers or browsers it needs to be running on, etc.).

So far this process has been working beautifully–thanks to our many large whiteboards and strong Scrum Masters. We are able to run through most of the stories queued up for the next sprint pretty quickly (less than an hour every two weeks), and identify the stories that need more thought before then come into Grooming.

Everybody gets involved: QA, Creative, Engineers, the PO. All grab a pen and start writing. It’s exciting and has really helped us cut down on stories that don’t get completed in the sprint.