Good User Stories enable the team members and project's stakeholders to INVEST in what is being set as an objective. The acronym and a question you can ask of yourself and others to determine if it really is can be found below.
- Independent -- Does this user story overlap with other user stories in your backlog?
- Negotiable -- Does it cover the essence of the objective or is it an explicitly defined contractual obligation?
- Valuable -- Does it actually add value, or is it something somebody wants done because that's the way it's always been done?
- Estimated / Estimat-able -- Is it clear and concise enough so the team members who need to be directly involved know what the expectations are? Do they agree, and can they paraphrase back what's been asked for?
- Small -- Yes, this is very subjective. We'll cover this in a near future post.
- Testable -- Is it vague or can unit, feature-function, and system tests (as applicable) be defined and the test results be objectively validated?
There is an acronym "SMART" for creating effective goals; and user stories.
- S – Specific -- this relates to the 'INV' parts of INVEST
- M – Measurable -- this relates to the 'EST' parts of INVEST
- A – Achievable -- this asks something INVEST doesn't ask. Do the people with the required skills, processes to follow, and tools (i.e. resources) exist to realize what's being asked for?
- R – Relevant / Realistic -- this asks whether the user story actually even fits into the scope of the larger backlog and project objectives.
- T – Timely / Time-boxed -- this relates to whether or not the story is appropriately estimated and prioritized.
ADAPT
- Awareness of room for improvement -- Do people want whatever this is going to produce?
- Desire to change -- Do they care or are they resistant to what this will produce?
- Ability to work in an Agile way -- i.e.: This is going to be a challenge if the people involved are used to a command and control style of management.
- Promote successes along the way to build momentum and get others to follow -- Does it?
- Transfer -- the knowledge of the impact of this so it sticks in people's minds and they want to keep doing this.
DEEP (for Product Backlogs) by Roman Pichler and Mike Cohn
- Detailed -- appropriately
- Estimated -- see above
- Emergent -- new items emerge based on customer and user feedback, and they are added to the product backlog. Existing items are modified, reprioritized, refined, or removed on an ongoing basis.
- Prioritized -- are most important and highest-priority items are implemented first
To ensure that the product backlog is DEEP, we have to regularly groom it. Grooming the product backlog is an ongoing, collaborative process that involves the product owner, ScrumMaster, and team as well as stakeholders.
All these factors (and aconyms) are important for the best user stories because ....
- As a customer, I have certain expectations on the functionality and usability of your product, and if you want me to buy your product over somebody else's ...
- As a stakeholder, I have needs to be met so what the project team produces I can inform, communicate and/or sell about on my own, and not inappropriately commit the product to doing something it doesn't actually do.
- As employees at different locations in different time zones the way this project is managed better work for me too.
