Each Team seems to develop its own repeatable patterns, which are examples or templates of Stories (and Epics) that contain common, reusable, information for work. At 3Back, we call these examples or templates of Stories, Storyotypes. The concept of Storyotypes was originally introduced in 2004 by Gerard Meszaros in his article, Using Storyotypes to Split Bloated XP Stories, which he presented at XP/Agile Universe 2004.
We use Storyotypes to help decompose Epics, as well as a tool to help a Team methodically capture, document, and reuse common Agreements, especially the common Definitions of Done.
Storyotypes typically look like a checklist of items that apply to a certain type of story. Here is a sample Storyotype for a coding story.
Once a Team has its own Storyotypes, they serve three primary purposes in helping the Team to:
- Find new Stories and Epics for the Backlog.
- Decompose existing Epics into Stories
- Have consistent, high-quality Agreements for those Stories.
The last two of these purposes are Backlog Refinement activities which prepare Stories for Planning. Storyotyping nicely captures patterns within these Refinement activities, making it a natural activity for most Scrum Teams.
Here’s 3 ways Storyotypes help your Team in their quest for high performance.
- Find New Stories and Epics
Typically, 80% or more of a Team’s Stories are ones they’ve seen before and are, therefore, good candidates for storyotyping. Storyotypes make analysis and Epic decomposition easier by helping the Team know what they’re looking for and also help a Team be more consistent. Storyotypes can also be made consistent across Teams, and is one of the few things that can help cross-team consistency without overly interfering with each Teams’ self-organization.
They are also useful to help prevent scope creep hidden in overhead activities. For example, a Team Member is less likely to independently agree to go on a sales call if he or she knows that there is a ‘Sales Call’ Storyotype. The existence of the Storyotype will give the Team Member the courage to say to the salesperson: ‘Ok, we’ll have to add a new Story for that sales call to the Backlog and talk to the Product Owner about prioritization…’ We find that the act of storyotyping reminds Team Members of the fact that all work is managed with the Backlog – that there is no magic, nothing is free.
- Hold Common Definitions of Done
As we’ve recently discussed in Done/Done/Done/Done, there are four levels of Doneness, and the notion of storyotyping applies to all four.
– Story Level
For Coding Stories, the Team wants to know what it takes to mitigate the production of Technical Debt, so that it will continue to produce Clean Code. This type of doneness can be captured in the Definition of Done section of each individual Story’s Agreement, or it can be a more global definition, captured in Storyotypes.
– Capability Level
Capabilities actually get released to Users, so there is an inherent definition of releasable for a given Capability. This can be thought of as Doneness at the Capability level, and since a Capability is simply an Epic, it extends the Agreement on Done at the Story level. Therefore, it can be captured as part of the Epic itself, or more globally in a Storyotype of an Epic. Keep in mind, though, that this definition does not guarantee releasability – it merely documents what we think may provide releasability – the Capability will still need to pass its Validations to actually be considered releasable.
– Sprint Level
Most Sprints have some common Definitions of Done, which involve things like ensuring the Sprint’s Goal is met, determining what to get feedback on during the Product Review, moving the integrated code to a test lab, preparing necessary metrics and reports, and so on. These can be captured in a storyotyped ‘Sprint Wrap-up’ Story, where each of these common doneness requirements is part of the Acceptance Criteria section of the Wrap-up Story’s Agreement.
– Release Level
What a Team does in order to release a Product is similar from Release to Release. The commonalities can be captured in a storyotyped Doneness Epic, consisting of a collection of Stories, each of which contains one (or more) of the little things the Team has to do.
Each of these levels of Done is important, and it’s natural for Teams to think about them. By capturing this knowledge in Storyotypes, it helps keep the Team from being stupid on purpose or forgetting things by being caught up in the moment. It also gives a clear topic to retrospect about, and gives a mechanism for documenting the improved knowledge of what Done is as the Team improves.
- Use as a Guide, Not as a Replacement for Analytical Thought
Even though Storyotypes are a great help for a Team doing Backlog Refinement, it must be stressed that the use of Storyotypes does not replace thinking. It’s tempting, when the Team has Practices, for the Team to allow the Practices to dominate their development efforts. However, it is the ScrumMaster’s job to make sure that the Team doesn’t let the Practices overwhelm the self-organization, self-management, and analytical thinking of the Team.
In particular, even though the Storyotypes may provide a template for a Story’s Agreement, the Team must still take a good, hard, look at the Agreement during Sprint Planning before they actually agree to it. The Storyotype is merely guidance, not dogma, and the Team must adapt it as necessary.
These Storyotypes are also an excellent topic for Retrospectives, as the Team is always learning about what works and what doesn’t. The Storyotypes’ Agreements should be constantly under revision as the Team inspects and adapts them. This is true even if the Storyotypes are common across multiple teams. Even though these shared Storyotypes constrain what the Team may do, the Team should still feel free to strengthen the Storyotypes to meet its own particular needs.
Storyotyping is an incredibly useful concept to reuse knowledge, document it and become more consistent, helping your Team inch closer to high performance.