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.
Also see the Good User Stories continued post! :-)
ReplyDeleteThe order of the approach used for INVEST is:
ReplyDeleteI – independent -- do the artifacts overlap and confuse things or do they clearly and cleanly delineate one thing that needs to be done (relative to all the other artifacts)
S – small -- is it small enough so that if you were trying to explain what is being done, somebody else new to this could understand within 15 minutes (ideally, 30 seconds) what is being done
E – estimatable -- if it’s small enough, everyone directly involved with creating the artifact and getting it to ‘Verified’ state should be able to agree on how big an effort this is, which people with what skills will be needed to carry this off, what risks, dependencies and prerequisites exist to be successful at delivering this user story / artifact, etc.
N – negotiable – next step so everybody leaves the table felling good and confident with the I-S-E above; including circling back on I-S-E above as many times as needed to get there. This is usually addresses during the Planning Poker exercise.
T – testable – if it truly is all the above, then the V&V prime(s) should be able to leave the table with everyone else and start to produce their test strategy, test plans, and ideally test cases.
V – valuable -- this is the final step to bring things full circle so you have a closed loop process. If everyone believes based on the above it is truly still adding value to the business in some way, shape or form then keep going. If not, people should be asking where did we go off the tracks, and should we still be doing this (or chuck it based on what everyone now knows based on the elaboration done to this point)? For example, if it's estimated as a feature or functionality that will take a year to develop but is also none of our customers really care about we have to ask ourselves if it's really that worthwhile doing. Likewise, if it turns out to be something everyone wants that can be produced with low effort and risk, this helps push that specific user story to the top of the To Do list.