Stories are not simply a replacement for a requirements specification. It is meant to be an interactive, regular, shorter process.
Focus on One significant thing
Don't do story writing workshop every sprint. It is a bad idea to do so.
Minimum Viable Product (MVP) is a good thing to focus on because it promotes feedback early.
Minimum Marketable Feature (MMF) is a subset of functionality that users need, but it is enough to be valuable to users when released.
Who should be in story writing workshops
Product Owner presents the significant objective
Scrum Master or Coach to facilitate the meeting and keep it run smoothly and effectively
Any other person that will be involved in the development such as Developers, Tests, Technical Writers, DBAs, Designer, Architects. Don't leave people out this is the time where everyone learns about the story. This will allow questions to be answered, new perspective brought in, and more new and innovative solutions will likely be produced.
An exception to this is when multiple teams are involved. In this case a subset of each team may be useful to keep the size of the meeting smaller and more manageable. An alternative would be to break the story down further so that each team can have their own sub-objective and meeting and the full team would be included in these smaller story writing workshops.
Users and Stakeholders can be invited and probably should be. However if it becomes too distracting or side-tracks the workshop because they are arguing over priority of stories then it may be better to leave them out. Alternatively, reassure them that the workshop is about understanding the user story workshop, and discussing it does not prioritize it over another story.
Visualize relationship between stories
A story map is quite useful for visualizing how stories relate. This is typically describing a sequence of stories connected with THEN.
Then add Alternatives below sequence at the position where it is in the sequence. Or keyword is used to connect it in the sequence. The higher priority items should be at the top, and low at the bottom.
This is helpful for identifying missing stories. To do so, ask the following questions while reviewing the story map. Ask these questions for each type of user in the user story.
- What will a user most likely want to do next?
- What mistakes could a user make here?
- What could confuse a user at this point?
- What additional information could a user need.
Subsequently you can then break story map into releases such that each horizontal line is a new version. It can be useful to label each version as well.