Let's first understand what Agile is.
Agile software development describes an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer end users. It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages rapid and flexible response to change.
The Manifesto for Agile software development,
- Agile software development principles
- Agile software development values
- Agile software development methods
If you want to learn more about Agile you can reference this,
https://en.wikipedia.org/wiki/Agile_software_development
Scrum is one of the popular Agile software development methods. If you want to learn more about scrum you can download the official scrum guide from this link,
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf
Before starting this blog, I want to list a few Agile keywords here so that if you are not aware of Agile, then you can understand the context.
- Product backlog items (Contains epics, features, user story, and bugs and technical spikes)
- Sprint backlog items (Contains user story, bugs and technical story)
- Sprint (Usually timebox ids normally for two weeks i.e. 10 days)
- Iterations (Get working software normally after more than one sprints)
Now let me disclose the rules to create a good user story in product backlog items in Agile.
- INVEST
- SMART
- MoSCoW
- DEEP
- FROCC
Each rule is equally important but INVEST is the most popular rule in order to create a good user story in product backlog items in Agile. Now, let me explain each rule one by one.
INVEST
Agile says that each story must "INVEST". An INVEST user story must be,
- Independent – The user story has no dependency to other stories
- Negotiable – User stories can always be changed and rewritten
- Valuable – A user story must deliver value to the end user
- Estimable – You must be able to estimate the size of a user story
- Small – A user story must fit into a sprint, but should be smaller
- Testable – A user story must be testable
All of the above points are very clear except point #3 (Valuable).
Many Agile practitioners do believe that each story should be valuable to the customer or user but I don’t believe in that way of thinking because business value incorporates more than just customer or user-facing value. It includes an internal value which is useful for things which are normally called “non-functional requirements” or something similar.
All stories should be connected to clear business goals. This does not mean that a single user story needs to be a marketable feature on its own.
The business value of the story, the “why”, should be clearly understood by all. Note that the “why” does not necessarily need to be from the perspective of the user. “Why” can address a business need of the customer without necessarily providing a direct, valuable result to the end user.
INVEST "Valuable" : Each story for the next sprint offers clear value or benefit to either external users or customers (outside the development team), or to the team itself, or to a stakeholder. For most products and projects, most stories offer value to external users or customers.
Hopefully, user stories are being prioritized in the backlog according to business value, so it should be obvious that in an Agile context, this means that each successive version of the product is usable, and each builds upon the previous version by adding user-visible functionality. These are called "vertical" increments.
"In a nutshell, each successive version of the product is usable, and each builds upon the previous version by adding user-visible functionality is valuable."
SMART
Make (iteration) goals always “SMART”
- Specific – Target a specific goal
- Measurable – Quantify or at least suggest and an indicator of progress
- Achievable – Be realistic
- Relevant – Check relevancy of the goal
- Time-bound – Assign a target-date
MoSCoW
When it comes to prioritizing your backlog “MoSCoW” can serve you well to help distinguish your features by:
- Must have – The requirement is core and must be satisfied for success
- Should have – The requirement should be satisfied for success
- Could have -The requirement is desirable, not necessary for success
- Won’t have – The requirement will not be implemented
DEEP
A well-refined product backlog is “DEEP”
- Detailed appropriately – The details are added over time
- Estimated – Backlog items are estimated
- Emergent – A product backlog changes over time
- Prioritized – The most valuable items are on top
FROCC
The Scrum values can be easily thought of with the “FROCC”.
- Focus – We focus on a few things at a time
- Respect – We respect our colleagues like we want to be respected
- Openness – We express our thoughts about how we are doing
- Courage – The team gives us the courage to take on greater challenges
- Commitment – We are committed to success
Note
Focus is very important in order to create a good user story in product backlog items in Agile as well.
If you follow all of the above rules while creating user storys in product backlog items, I am sure that user stories will be very good for development, testing, and delivery.
If you have any query or concern just let me know or put it in the comment box and I will respond as soon as possible. I am open to discussing anything, even silly questions as well. If you have any suggestions related to this blog, please let me know. I promise I will improve this blog to a maximum level.
References
- https://stwunder.wordpress.com/2015/05/06/5-most-powerful-acronyms-for-agile-coaches/
- http://agilefromthegroundup.blogspot.in/2009/12/agile-software-construction-is-like.html
- https://agileforall.com/new-to-agile-invest-in-good-user-stories/
- http://www.agileadvice.com/2015/04/15/referenceinformation/summary-of-user-stories-the-three-cs-and-invest/
- https://en.wikipedia.org/wiki/Agile_software_development
- https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf