Good user stories are the lifeline of Agile Projects. Well defined the user stories and done criterion are, greater the chances of high quality software development. Remember INVEST when creating the user stories. What’s INVEST? Read on.
Before we get into the details, let’s quickly talk about User Stories in general.
What is an User Story?
User Story is the description of end user needs, expressed in terms of the business value. It is normally written in a simple but definite unambiguous form.
There are several formats or templates to write an user story, but here is the popular one.
As a <<Business User>>, I want <<Goal / Desire>> so that <<Outcome / Result that gives Business Value>>
- This format is simple and easy to understand
- It captures the essential needs of the end user
- It forms the foundation for a good done criteria
Here is an example:
As a System Administrator, I want to manage the access rights of application users so that I can grant or revoke access as needed with minimum delay.
The INVEST Guideline
It is not an easy task to write good user stories. But if you keep the INVEST guideline in mind, chances are high that you will fork out an excellent one.
- An user story must be an independent entity
- This enables the user story to be either picked or dropped from an iteration, without impacting others
- Also this makes it easy for someone to pick the story and take it to completion
- If not entirely possible, try to minimize dependencies with other stories
- A good user story must be closed-ended with business need but open-ended with the solution
- It must be possible to negotiate with product owners and end users on an optimal solution to implement the story
- If the story is too tied to a particular solution, it is hard to innovate and simplify
- What business value does the story deliver? What are the benefits to the end user once the story is implemented?
- These are important questions that the Product Owner or Business Analyst must answer before finalizing an user story
- Without a right value proposition, it is extremely difficult to prioritize stories
- This is a tough attribute of an user story!
- The creator must put him or her in the shoes of development team and see if the story is estimatable
- By this I mean, the details are sufficient enough for the team to estimate and plan for implementation
- A Business Analyst with a development background is handy in this situation – he or she can review the story and see if more details are needed to make it estimatable
- KISS principle is very well suited for user story creation
- Keep it very simple and easy for everyone to understand
- Avoid using business jargon whenever possible
- Avoid open ended or vague statements that may lead to ambiguity
- Have it peer reviewed by other product owners to ascertain the level of simplicity
- Remember: Simplicity is the ultimate sophistication
- Testing is an essential piece of Agile Software Development
- It is performed at various levels to confirm the quality of delivery
- An user story must be testable – developers and testers must be able to understand the stories and start writing tests to validate them
- A good done criteria is also essential for a better quality of test cases
- Once delivered, the stories must be testable for better validation
Here are some guidelines to follow that help with the creation of Good User Stories:
- Make them Independent and reduce dependencies
- Keep them Negotiable – neither too open for ambiguity nor too closed for optimal solutions
- They must provide some tangible Business Value
- Development teams must be able to provide Estimation for Implementation
- Keep it Simple…
- It must be testable!
What is your experience with user stories? How do you handle the tough job of making good user stories? Please share your ideas with us.