In what situations should a template be used for writing stories? When would the lack of templates cause issues? In this blog, I wanted to put out the case both for and against creating and using a story template. In particular, stressing the importance of creating a balanced view. Feel free to join in and add your own.
FOR templates: Situations where it is good to have a story template
-
When every business analyst, or every team, is putting out something significantly different to the point where it becomes difficult for anyone else to know if a user story has been analysed enough for development.
-
If you are in a highly-technical project and the domain is not as straightforward to write user-driven stories; you see many attempts have been made to write system-driven stories.
-
When setting the right expectations to stakeholders of the team. It may be easier to communicate that a story is well-understood enough when the relevant details are captured.
-
When you want to provide a pattern of cues for developers and QAs to look out for. For example, make sure that all the assumptions are captured in the Assumptions section, or the navigational flow is in the User Journey section. A template ensures that they are always in the same place in the stories.
AGAINST templates: Situations where it is not a good idea
-
A template is a guideline, it should not be followed word for word, just for the sake of it.
-
It is a hot bed for anti-patterns! Some technical stories do not naturally fall into nice sections in the template, same for some UI stories or cross-functional stories.
-
Sticking to a strict template - and the enforcement of not doing this any other way - will cause analysts to only think within the constraints, instead of thinking what might be useful in solving the root cause of the problem.
-
A rigid template may leave empty sections in the stories, where some sections are not applicable. As the the team become habituated to skipping through these blank sections, it leads to them also skipping otherwise important information.
Afterthought
As with many tools and techniques that sit in the toolbox of the business analyst, one has to practice the art of figuring out what works for you at that given point in time. It is worth remembering that you always have to tweak the precise amount of information that is needed in each project; there really is no lazy way to go about it blindly. Get back to the basics about making story writing into a conversation. Tweak it, evolve it over time - checking that whatever you are doing is still getting you to the goals that the team is trying to achieve. It is never the case of sticking to one template or format and declaring that this story writing thing is "done". You will find that what worked perfectly in one project would be a disaster in another -- yes, this does happen. The key here is to get feedback from your team members, to gauge whether something needs to be added or taken away. Remember, being a good analyst is not about writing the perfect story at the expense of having a shared understanding; it is about using a technique to help you build the most efficient team.
