User stories are described by the Product Manager/ Product Owner, deliverable to the Development Team to build the product. Development Team will have to implement the user stories. It seems pretty clear and simple, but it’s not really that simple. Development teams usually face problems with the stories. They don’t really understands what the stories saying. Sometimes Product Team and Development Team both go through the “armageddon” because of the quality of the User Stories.
As its name says it, User Story tells a story and it explains expectation of users. It describes how the users will use this product. So before writing a user story it is very important to find out and understand why user would want to use this product. User story can’t be written by only guessing what user would want. Before producing user stories, we must need to take some time, collect all information, understand user perspective to avoid ambiguity.
Confusion between User Story and Task
- As a User Story is described by the Product Team and implemented by the Development Team, it delivers value to the Users. And a task represents development activates that is clearly related to development and not add value to User.
- Product Owner clearly describes the stories which helps to build the right product for the Users and after that Development Team breaks those stories into tasks.
- User Stories gives the developers a clear idea of what they are developing and why. While tasks are a single type of work that is to make sure development process is well defined.
- User Stories can not be fully done by one person, it needs a team effort like Product Team, Designers, Development Team, Quality Assurance. And a task is written by the Development Team or can be done by one person.
- Product Team focus on right users and the product goal. And the Development Team breaks it down in tasks.
Quality of User stories:
A good story helps the Development Team to build a good software where a bad story leads the team to build a poor quality software and make customers that complain.
By bad User Stories, Development Team builds poor quality software that is not what customers really want, leads to miss deadlines, rebuild or fix it. Effects of bad stories:
- Hard to figure out what really meant by the story
- Need to research while developing the product
- Need to wait for external help to understand the story
- Build something that is not what customers really want
- Leads to wrong definition of acceptance criteria
- Developers will not be able to use their skills to build the best possible solution for the customers
Tips to produce better User Stories:
A good story can make anyone (related to the development) comfortable to understand the product features and product goal. Helps technical team to implement the best possible solution. Here are few tips to produce better User Stories:
- Focus on right USERS. We always need to understand the users, put ourselves to the users shoes. Try to understand what they want and why? How would the user want to use the product, so that we will be able to go to the right way.
- User stories should be created with the involvement of the related teams (Development Team, QA etc.) to get more questions and more ideas to write a better user story.
- User stories should be created with important criteria: understandable, right sized, easier to review flexible to fix, testable and able to be Agile.
- Adding acceptance criteria.
Right user story can help the team to develop faster. Develop software quickly as possible and the team can add more business value to the product.