In any Agile project one of the major factor in success of project also depends on the way user stories are written. User stories are the basic building blocks towards the overall project’s requirements, these are complete units that can be build tested and delivered.
Many a times, I have experienced that user stories are very high level and lack the level of details required to fully understand the requirement and that further results in clarifications, sometimes oversights and the end deliverable mismatch because of the assumptions made by the delivery team.
User stories should be written for each action, for example: As a User I should be able to login to access my dashboard. Now this user story is emphasizing towards the login action and then after login User must be able to reach to dashboard. It would be not a unit level story if I write: As a User I should be able to login to see the list of my most recent messages on dashboard. Rather correct user story for this would be: As a logged in User I should be able to see the list of my most recent list on dashboard.
User story is not complete unless there is good level of details to be understood by the development team, It might be possible the stories are first written on a high level with just the title and that would be enough for the discussion with business owners etc. But as we start talking about the details of the stories like: what will be the business logic towards the message getting displayed after I have reached the dashboard after login, one way is to write another user story that says: As a Logged in user I should be able to see successful display message after successful login. This is a perfectly fine way to document the requirement but then there would be a very large number of user stories just for the login itself, let me try one more: As a User I should be able to see error message on unsuccessful login attempt.
So I started to experiment in User stories and found a good way to document the details in user stories by adding following details:
- Business Logic : This is generally a simple language that is more detailed to help in understanding the story
- Screen to display : If there is any screen to be displayed, like Login screen and Dashboard
- Success Action: In case of success what action might be needed to be performed
- Success Message : Once the action is completed if there is any success message to be displayed, this can also in included in Success action
- Error Action: In case of error if there is any specific action to be performed
- Error Message: If there is error what must be message, this can also be included in Error action
- Before Action: Before the action is performed, if there is anything additional to be done that would be written in this
- After Action: If there are tasks to be performed after the Action is complete, that would be mentioned here
- Prototype: If there is a UI Interface to be made, this particularly helps in giving the overall idea about layout expectations
- BPMN(Business Process Model and Notation): This helps in understanding the business flow for this user story
I have experienced when I started adding these details to the user stories, it became easier to not only write less number of user stories and complete the larger set of Product backlog but also less effort towards the details required for the development team that would need less clarifications later.
However these details can not be written only by the Product Manager and needs support from the Project Manager and his team as well, but it is always good to have blank template of user story with these fields so that the details can be filled if required.
It is recommended to make some of the above fields mandatory based on the projects requirement, like Business Logic would always be there and so is the BPMN.
These fields are not exhaustive and I have used these based on my web based Projects and with the Agile teams for deliveries. It might be possible that you may be writing the user stories in completely different format and this looks very different to you, but my recommendation would be to try this and customize your fields according to the details you want to add to the stories.
Let me know your thoughts on this or any of you experience with the user stories in comments below.