Stories 101 for Scrum Masters
As a Scrum Master you normally will not write stories. But it is critical for your role as a Sherpa (an expert) to know how to guide your developers so they do not accept into their Sprint Backlog stories that are not well-formed and clear. Remember that your developers are the ‘factory’ to create ‘what’ the Product Owner wants. If the factory is not provided high-quality fuel, the production line may create something quite other than is expected.
So, how can you as a Scrum Master know that a story is 'good'? Two ways: one by the story structure, and the other by the quality of the story content. To keep this simple: here is my 'Cliff Notes' explanation of these two criteria so you can develop an intuitive appreciation for what your developers really need from a Product Owner.
Story Structure
Each story should have at a minimum:
- A title that begins with a verb. If you follow the “As a <user> I want <function> so that…” form, the function phrase should begin with a verb (an infinitive form).
- A clear statement of what is in-scope and out of scope. Scope can be specified by describing execution scenarios (happy paths and exception paths) to be implemented.
- A specification of one or more execution scenarios that allow development to be partitioned and achieved incrementally.
- Specific and accurate specification of the conditions that must be met by the story implementation for each execution scenario that is in-scope. These are the acceptance criteria (ACs).
- A section to accumulate questions from the developers, so these can be addressed through technical design sessions, or in conversation with the Product Owner.
Content
- The verb title should describe the result or goal to be achieved by the story implementation. Pro tip: If the title and ACs do not align to the same goal, something is wrong with the story.
- Execution scenarios are just that: a specification of each flow to be implemented in the story from beginning of execution to one of three terminating conditions:
- The execution successfully achieves the intended goal without any interruptions. (Happy path)
- The execution achieves the intended goal, but a runtime condition interrupted the flow and the code had to retry and was able to recover. (Happy path with recovery, or exception path with recovery)
- The execution does not achieve the intended goal because of a runtime condition that could not be overcome. (Exception path without recovery)
If you think of the execution space of the story as a directed graph, the execution scenarios are all the possible paths from the beginning of the graph to one of the terminating conditions above. Additionally, if you envision this directed graph as vertical with execution flowing from top to bottom, if you rotate your mental model 90 degrees counterclockwise you will have a new model that is surprisingly similar to the structure of a UML Sequence Diagram!
ACs must describe observable runtime behavior, or observable outputs which are the desired or expected end-state of each execution path that is in-scope.
ACs define everything that is in-scope. Everything else is, therefore, out of scope.
ACs allow the developers to determine if the story fits within one (or one-half) sprint.
If the ACs erroneously describe the development activities for producing the solution rather than the conditions for verification and acceptance, then neither you as a Scrum Master, nor your Product Owner, understand ACs at all.
If a story has no questions from the developers, you have either
- A Product Owner who is a miracle worker and a genius at specification, or
- The developers are coasting and making potentially careless assumptions.
If your developers cannot sketch out, or otherwise articulate, their design thinking during story refinement, you should prepare for in-flight surprises during the sprint.
I love working with teams and executives to find effective solutions. Email me at gary@effectivescrummaster.com and let's explore how we might partner on your challenges.
