User stories are an essential part of Agile software development but what really are User Stories? In this post I will try to demystify User stories.
Mike Cohn in his excellent book “User Stories Applied” gives us a definition of a user story as the one which “describes functionality that will be valuable to either user or purchaser of a system or software”. Thus a typical example of a user story would be “As a registered User of website I want to buy products online”. Here a value for the user would be an ability to buy products online.
A user story is written in a typical format like As a ….. I want to … so that … although it must be pointed out that it is not a requirement to write the stories in this format. Ron Jeffries gave us the 3 Cs associated with these User Stories viz. Card, Conversation and Confirmation. The card refers to the expected functionality in not too detail form but coupled with conversation those details are determined and confirmed before that story is picked up by a team member for development. Conversation need not be happening just before the story is picked for development but as part of development process till the story is completed. The conversation around a user story means that there is a high degree of collaboration between the team members resulting in increased shared understanding which is most valuable for collaboration.
As the stories are added to the product backlog at some point they will need to be brought into a sprint for development, but how do we know if they are “ready” for a sprint? A popular way to decide that is following INVEST criteria for user stories. INVEST is a mnemonic based on
Through conversation happening on a regular basis and especially at backlog refinement sessions these stories are refined based on the above criteria to ensure that they are ready for the upcoming sprint for development.
One of the criteria for a user story to be Ready for development is “Small” which determines whether that story will be complete in half a day to two days by a developer. If the team thinks that it is not feasible for that story to be completed within that period then it may be required to split that user story.
Richard Lawrence in his post suggests that a story is split based on these guidelines
• If a story is based on a workflow then breakdown the workflow steps as individual stories
• If there are variations to business rule specified in a story then each such variation can be used to split the original story
• Sometimes a major effort is needed upfront to support variations in functionality to be implemented, so that part can be one story and variations can be split into smaller stories
• A complex story can be split by determining on its simplest form and then adding other complexities as part of other stories
• A split can be based on variation of data the story acts on
• A story may need to incorporate different interfaces for user input
• Deferring non-functional requirements to other story / stories
• A split can happen on operational activities