Why it pays to INVEST in user stories

by Dean Peters

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 handshakes 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.

Title

Demonstrate the INVEST principle via a user story

User Story

As the modern product manager Dean P., I desire a user story built on the INVEST principle so I can empower my teams with owning how to build value for our customers.

Description

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, ADO, VSTS, Rally, etc.

In short, this means that the deliverable is a user story that itself adheres to the INVEST pattern and whose format can be nudged to perfection on a product owner by product owner basis where it is:

  • Independent – is minimal or devoid of dependencies
  • Negotiable – open for conversation, refinement, & splitting
  • Valuable – addresses the user’s desired outcome & target behavior
  • Estimateable – not so big or vague that it can’t be sized, or split
  • Small – aim small, miss small in terms of estimations
  • Testable – can be tested in a crisp, user-focused acceptance criteria

Guardrails (optional)

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.

Acceptance Criteria

(a.k.a. UAT, a.k.a. User Acceptance Test)

  1. 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.
  2. 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.
  3. 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.
  4. 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 product owner has shaped the story so it is small and well-focused
    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.
  5. Breaking down one big story into several small stories when needed
    GIVEN the success, parameters, and results of UATs 1 through 5 above
    and GIVEN that the product owner understands that shaping a story small ensures more reliable estimations
    and GIVEN it’s not really the 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.
  6. 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 the product manager will engage a 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.

Subtasks

(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.

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.)

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.

YMMV