Invariably, when I introduce the concept of a “Story Time” meeting to a Scrum Team, there’s always one or two members who give me a puzzled look. My explanation typically includes an acknowledgement that it’s a silly name but one that describes the purpose perfectly. Basically, during Story Time meetings, the Product Owner “tells a story” of what the upcoming backlog items are all about and the Developers have an opportunity to ask questions and understand what is intended.
As an experienced Scrum Master and Product Owner, let me assure you that these meetings are invaluable. They are best scheduled mid-sprint and if time permits, after a sprint’s review and retrospective meetings. While the primary goal is for the Developers to get a preview of upcoming backlog items, the secondary goals are also important. The general flow of the meeting goes like this:
(1) The Product Owner introduces upcoming backlog items, providing context and explanation of acceptance criteria.
(2) The Developers discuss each backlog item, asking questions to clarify understanding and provide feedback regarding the scope, dependencies, and design considerations. The Product Owner answers questions and records the information as backlog item notes or integrates them into the acceptance criteria. (The updating of each backlog item can be done on the spot so long as it doesn’t disrupt the flow of the meeting.)
(3) Once the Developers have enough of an understanding, they assign relative effort estimates (T-Shirt Sizes, Story Points, etc) and those are recorded with each backlog item. At this point, the backlog item is considered “Sprint Ready” and can be selected during the next sprint planning meeting.
(4) The exercise continues so long as there’s time left in the meeting.
This meeting works best when both parties (Developers & Product Owner) see this as an opportunity to improve the chances of successfully delivering completed backlog items. The Developer feedback helps the Product Owner refine the upcoming backlog items where even minor wording changes can make a big difference and the Developers benefit from learning details ahead of time and are able to influence backlog item scope.
© 2012 William Patrick Swisher