The term storyotype is not well known in France however the concept could help some teams who can not always do a classic user-story.
Origin of user stories?
Today, the user-story is linked to the Scrum as a part of its DNA; however, the user-story does not come from Scrum but Extreme Programming.
Do I do Scrum if I use user-stories? Yes, the user-story is a more structured item (term used by the Scrum Guide) that brings more quality.
Indeed, the Scrum evolves and the user-story has become essential in Scrum because it responds perfectly at the needs. However, if some projects can use user-stories, this is not always the case.
Some people will use the Spike for research because the concept adapts very well to certain situations; the teams that use it are generally very happy.
However, that will not answer everything. On very technical projects, the user-story is impossible and the spike is not necessarily always adapted.
The storyotype appears at this moment
This concept is to say that there are several different types of items; for example, we could have user-stories, technical tasks, bugs …
When we use this concept, we change a little the deal because we will also achieve a Definition of Done (and Ready) by type of item; the idea is interesting because it will be curious to do functional tests on a technical task like refactoring contrary to an user-story.
Some people will shout, “It’s not Scrum !!! “. In fact, it’s completely Scrum because you adapt the method to context. Exactly as the 99% of Scrum projects today that use user-stories.
It is easier to recognize your items if you use one color per type of item. Do not hesitate to put a little legend on the wall board to remind the type of item represented by each color.
In the applications of the Kanban method, we also use the concept of a card called “classes of services”.
What changes for the Product Owner?
We can empower someone other than the Product Owner with the storyotype concept.
For example if we have a type of story “refactoring” because we are in the presence of an aging application that has a lot of legacies; it is logical that it is the developers who write this type of technical items and who validate their passage in “Done”.
On the other hand, the developers will have to defend their tickets against the Product Owner because it will be the only one to prioritize the whole of the Backlog.
This little-known method can be very useful to improve your Scrum or even to adapt it to situations that are impossible to manage correctly by being forced to work with user-stories.
I hope that this practice will be useful to you in the future.