Some Agile INVESTment Advice

TL;DR Use the INVEST principle as a sanity check when writing new user stories, splitting existing ones, and planning sprints to reduce risk and achieve sprint goals more consistently. It’s short for Independent, Negotiable, Valuable, Estimable, Small, and Testable. All user stories should meet these criteria.

Writing high-quality user stories is hard. It’s a time-consuming process that, among other things, involves:

  • Capturing a concise description of the target user persona, desired outcome, and user/business value (i.e. — as a <user persona> I want <some new functionality> so that <some value is created>).

User stories often start as vague ideas that evolve into more specific actionable requirements through activities like research, discovery spikes, conversation and healthy debate among scrum team members, preliminary design, experimentation via POC’s and MVP’s, etc. The time required for a user story to reach a ready state (depending on the complexity of team’s Definition of Ready) can often be as much as lengthy as implementation of the user story itself. Add a layer of administrative overhead to the mix to document stories in your ALM tool of choice (Jira, Azure DevOps, etc) and one begins to wonder how anything gets done at all.

And yet, after all of the effort poured into writing user stories, teams often still struggle in execution. User stories drag on for longer than their initial estimate and are carried over from sprint-to-sprint, compromising sprint goals and delaying value realization. The INVEST principle can help avoid these missteps by consciously enforcing strict requirements on the user stories that a team pulls into a sprint.

The INVEST principle offers guidance for the pre-conditions user stories must meet before being pulled into a sprint — think of it as an informal Definition of Ready (DoR). It’s an easy to remember acronym to help you write better user stories, plan low-risk sprints, and improve sprint-over-sprint performance. It doesn’t stop there either — the same logic can apply to epics and larger work item types used to organize and plan your work.

The following is a description of each component of the INVEST principle:

I — Independent

User stories should be free from dependencies on other user stories or people outside of the team performing the work. Dependencies are difficult to control and pose a risk to sprint goals if they are not tightly managed. Whenever possible, defer stories with external dependencies to future sprints, after which they have been resolved.

N — Negotiable

User stories represent an invitation to a discussion regarding the optimal path to achieving the desired value. If the ultimate goal is to build amazing products that delight customers, then user stories and their acceptance criteria cannot be set in stone. We must remain nimble in the face of changing customer needs and adjust our requirements to align with them. User stories are not contracts — constructive, ongoing negotiation is encouraged between the customer, product owner, and development team to agree on how best to achieve the goal, even after development work has begun.

V — Valuable

User stories must provide value — either to the user or business. Wherever possible, estimate the value either quantitatively or qualitatively, with a preference to the former.

E — Estimable

All components of a user story (description, acceptance criteria, test cases, etc.) should be sufficiently clear such that a reasonable effort estimate can be derived. The team doesn’t need know the exact implementation details yet, but a universal understanding of the relative complexity must be achieved across all members of the development team.

If further clarification is required, utilize the infinity symbol during your planning poker sessions to raise concerns that warrant further discussion. Create a discovery spike to answer any lingering questions and revisit the user story estimation in the following sprint.

S — Small

Borrowing from the lean Agile principle of small batch sizes, smaller user stories tend to move faster through the software development lifecycle (SDLC). The smaller the user story, the easier it is to understand the technical complexity and fine details, and typically results in a lower test effort required to validate acceptance criteria.

All user stories pulled in during Sprint Planning should be started and finished within the sprint bounds. Establish a maximum user story size permitted to be pulled into a sprint and split all stories exceeding this size (ex. — if you’re on 2-week sprints and using the fibonacci sequence of 1, 2, 3, 5, 8, 13, …, many teams cap committed user stories at an 8 and split those that exceed this size).

T — Testable

User stories must be verifiable and are not considered done until tests against their acceptance criteria, whether automated or manual, have been executed and pass. By having testing discussions up-front, before development begins, new requirements are often uncovered, resulting in a more robust product with quality built-in before it reaches the customer in a production environment.

INVESTing (!!!) the time to write high-quality user stories yields many benefits, including:

  • Reduced Risk: Large user stories, external dependencies, vague acceptance criteria, and/or those that are misaligned with user needs, etc. each represent ways risk surfaces in the work we do. Pulling user stories into sprints that adhere to the INVEST principle sets sprints up for success by proactively managing the major points of risk.

Now get out there and INVEST in writing better user stories during your next Sprint Planning or Backlog Grooming ceremony and let me know what you think — I’d love to hear your experiences (good or bad) in the responses!

The Startup

Get smarter at building your thing. Join The Startup’s +730K followers.