TL;DR — Love’m or Hate’m, it’s hard to deliver software that matters without user stories that are independent, negotiable, valuable, estimable, small, & testable. Here is one way you might want to make this magic happen.
As you may be aware from some of my other posts, I attend some not-to-hush-hush meetups here near Raleigh where product managers and product owners get to exchange secret hand shakes and commiserate on common pain points. While I am not at liberty to divulge the former, one pain point that I’m free to discuss is that of user stories.
During such dialogs, you can bet the bicycle that I’ll at some point pontificate on the value of incorporating INVEST principle into one’s story construction. But rather than dryly describe each idea behind said mnemonic, let me try to incorporate its concepts in a format you may find of use, set against the assumed personas of both myself and that of an average agile team.
Demonstrate the INVEST principle via a user story
As the modern product manager Dean P., I desire a user story built on the INVEST principle.
The scope of this work is to quickly demonstrate the INVEST principle in a user story format that I’ve found works well in various ticketing systems such as JIRA, VSTS, Rally, etc.
In short, this means that the deliverable is a user story that itself is Independent, Negotiable, Valuable, Estimatable, Small, and Testable; and whose format can be nudged to perfection on a product owner by product owner basis.
These are team negotiated bullet points based on the Agile principle ‘Simplicity is the art of maximizing the work not done.‘ Optionally are follow-up activities, and perhaps even some specific implementation items to ensure the story remains small and estimable. Regardless, this item mostly serves the engineering team!
- This is a good place to say “For this 1st iteration, we’ll limit the work to just enough of whatever it takes to get feedback from users, and no more.“
- It’s also okay to say “For the 2nd iteration — which will occur in the following sprint — we will nudge the solution to perfection based on feedback.”
- You can use the guardrails to negotiate with those outside the team who might swoop in with late-breaking additions to the current story.
Value Proposition (optional)
The primary measure of success will be the analytics metrics on usage such as the number of times this template is used coupled with feedback from key end-users and depending on the context, certain stakeholders.
Secondary measures of success could be NPS scores on surveys associated with this template, claps on Medium, likes on LinkedIn, and/or direct email.
This can be treated as a follow-up, or post-mortem item added to the story after its been implemented for a finite period of time.
(a.k.a. UAT, a.k.a. User Acceptance Test)
- Creating a user story that is independent
GIVEN an Agile software team
and GIVEN a problem to solve from customers, stakeholders, Agile Team members, etc.
and GIVEN the product manager hopefully has engaged in a 3 amigos conversations with select members of the Agile team
WHEN the product manager creates the story
THEN the story will be rendered independent of various acts of tight-coupling to other stories, works, and processes that may impede the story’s delivery and/or introduce dependency-based fragility to the feature.
- Ensuring a new story is negotiable
GIVEN the success, parameters, and results of UAT 1 above
WHEN the product manager creates the story
THEN the story will be written in pencil, as a ‘promise of a conversation’ with the team and stakeholders … something negotiable rather than some IEEE 830–1998 commandments engraved in stone, brought down from a smokey mountain top.
- Equipping the new story with value measures
GIVEN the success, parameters, and results of UATs 1 & 2 above
and GIVEN there has been defined and/or identified a tangible value
WHEN the product manager creates the story
THEN the story will include a means of measuring said value.
- Getting the story ready for estimations
GIVEN the success, parameters, and results of UATs 1 & 3 above
and GIVEN the feedback from negotiations from UAT 2 above
and GIVEN the Agile team possesses an average story size of 5 for work completed during a single iteration (total story points of completed work per last 3 to 5 sprints / total number of completed stories per last 3 to 5 sprints)
and GIVEN the user story is ready for refinement
WHEN the Agile team holds its weekly estimations meeting
THEN the story will receive a Fibonacci-based value representing a size relative to other work the team has sized and completed in the past.
- Breaking down one big story in to several small stories when needed
GIVEN the success, parameters, and results of UATs 1 through 5 above
and GIVEN it’s not really a desired practice to split a story once it’s been pulled into a sprint (though sometimes this happens with learning)
WHEN the Agile Team attributes to a story a size of 13 or above
and THEN the product manager gladly agree to further break down the use case, possibly into a set of smaller stories as there is no way a 13 is going to get done in a single iteration or sprint for a team whose average completable story size during that time frame is 5
and THEN the product manager might want to hold further stakeholder and or customer meetings on any story of a size greater than 21 as it would seem we may have an entire feature set on our hands, if not a small t-shirt sized epic.
- Equipping the story with tests
GIVEN the success, parameters, and results of UATs 1 through 6 above
and GIVEN there is a repository of test cases
WHEN the QA engineer creates or updates testable cases, hopefully in a Cucumber-ish or Gherkin-like format, based off the user story’s the acceptance criteria, that includes both a good mix of rainy day and perfect world scenarios
THEN then product manager will engage walk-through of some or all of the text cases to get a feel for whether or not the test cases align with the story’s acceptance criteria.
(Here is where you bribe your JIRA/VSTS/Rally admin to create an extension to auto-generate subtasks that reflect your organization’s definition of done. The team can decided if any or all of them are relevant on a story-by-story basis … especially as what I’ve enumerated below is likely overkill for Agile Scrum peeps.)
- QA — Create Test Cases
- QA — Execute Test Cases
- QA/DEV — Write Automation Tests
- DEV —Write Unit Tests
- DEV — Technical Notes
- DEV — Write the Code
- DEV — Code Reviews
- TEAM — Push the build to a pre-release lab
(makes for yet another integration test opportunity)
- PO — Walk thru the acceptance criteria
- PO— Usage Notes
- PO — Release Notes
- PO — Demo the feature
Love’m or Hate’m, you need to INVEST your user stories if you want software success
My 6-part series on each element of the INVEST approach
These were written AFTER this article. Some people have already called me out on some of the differences. Such is the risk of continual learning and understanding.
- I is for Independent — Part 1 of 6 of ‘Why it pays to INVEST in your User Stories’
- N is for Negotiable — Part 2 of 6 of ‘Why it pays to INVEST in your User Stories’
- V is for Valuable - Part 3 of 6 of why it pays to INVEST in your user stories
- E is for Estimable - Part 4 of 6 of why it pays to INVEST in your user stories
- S is for Small - Part 5 of 6 of why it pays to INVEST in your user stories
- T is for Testable - Part 6 of 6 of why it pays to INVEST in your user stories
Artifacts & Related Links by Others
(A picture is worth 1000 words. A good article on a technical concept, likely worth 100 lines of code. So here’s where you reference Screenshots, videos, tedious Excel tables, links to other stories &/or stack overflow, etc.)
- What does INVEST Stand For? | Agile Alliance
- 10 Tips for Writing Good User Stories — Roman Pichler
- User Stories and Data — John Cutler — Medium
- User Stories: Ready, Set, GO! — RGalen Consulting — Bob Galen
- The Humanizing Work Guide to Splitting User Stories — Lawrence & Green
- 8 Steps for Effective User Stories — DZone Agile
Now pleeeeeeaaaaasssseee keep in mind, the above is not a prescription as much as it is a recommendation fully loaded so you can pick out what you like. It won’t hurt my feelings if you ignore the rest, or do things differently.
For example, some teams would insist — and with valid reason — that the part about the test cases is dealt with as a team-wide refinement gathering held prior to story sizing/estimation meetings. Similarly, automation DevOps types might argue the test cases == acceptance criteria, where Product types might want to keep them separate as said criteria is more about presenting the feature scenarios from the viewpoint of the customer.
And yeah, all those sub-tasks, yeah, probably too many for practical purposes, but they are there if you want them. Or you may find 2 or 3 such as “QA actions”, “Dev code tasks”, “PO sign-off” is just enough for your operation.