How to write good User stories?
Writing good user stories is always a challenging job, In this process you always try to inline with the standards and business goals. For me it is just an initiative for any task/feature to our product and gateway to give the insights of product to the Development Team. Now let’s see User Stories by the definition. What Are User Stories?
A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the software user’s perspective.
So by the definition user story is the smallest unit of work which leads to build one of the feature of the product. A perfect user story must cover the customer importance for what purpose we are planning and what exactly is plan for. Typical user story format is as below.
As a [Persona], I [Want to], [So that].
Where ………. “Persona” is the who for which the work is being planned. “Want to” is defined for what exactly we want to achieve, here we don’t have worry about the approach. How we will achieve, that’s completely out of it. “So that” here we are talking about the how the business is gonna use, what are the benefits of it, How it will fit into the customer need at the overall.
- As an user, i want to add the download process to our media application, so that customers can download their desired songs/media.
- As a manager, i want to be able to track down the assigned work, So that i can start planning the task priorities.
- As an user, I want add google maps feature to the application, so that user can search their destination to travel.
This all the theoretically true to follow the legacy User story writing, In my opinion User story may or may not follow the template but it should follow the below.
- Always focus on “What” Not “How”
- Try to keep short
- Understand your User
- Good Understanding of Customer Values
- Cover as much as key points.
- It should be one step of the one product feature
Why we need user stories? In Agile development, Requirement is the only thing which never gets freeze in most of the cases or in all the cases. So then as a Product Owner, whole product has to define or listed down with all the features and functions in Product Backlog. Product Backlog consists of list of user stories which can be converted into tasks.
As we have seen, the user story is the individual entity by which we can start building our product without knowing the bigger picture of the end product. Couple of User Stories can be a bundle for one Product feature. If we want to discontinue any of the feature or part of feature, it’s alway easy to track down and manage the piece of development we have done.
User Story versus Use Case: This is tricky you know, i have been hearing a lot about the Use cases, like if we are working in Agile then is there any need of use cases? Since we have User stories they are pretty clear enough then why do we need use cases. So it’s as simple as user stories, User stories are defined to give you what are building and to whom and why. On the other hand use cases are like “How user (Who) is gonna interact with the application”, i mean how they are gonna use it. Let say if we take the first example of putting download functionality in the application. What happened if user pressed the download button twice? Or if the internet stops during the download. These scenarios are helpful to see the outcomes of user actions or all the possibilities of use of the feature was build based on User story.
There are many myths about use of both, Do we need to use the Use Cases with the User stories? In my opinion we should use both together Use Cases helps to validate the build based on User Story.