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>).
- Defining acceptance criteria that are sufficiently detailed to achieve the desired outcome, capture the intended value, and cover both functional and non-functional requirements.
- Writing test cases that adequately cover all conceivable positive and negative test scenarios (if you adhere to TDD).
- Providing an estimation of the story size that is a reasonably accurate representation of its technical complexity, inherent uncertainty, and effort to complete.
- Splitting the story into smaller increments (if possible).
- Prioritizing it in the appropriate place among other work in the product backlog.
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.
- More Predictable Teams: Consistently achieving sprint goals will result in more stable team velocity, allowing for more predictable output over time and enabling reasonably accurate long-term planning.
- Happier Teams: Nothing is more frustrating than not achieving goals. Doing this over and over again can have a disastrous impact on team morale, leading to reduced work output, churn, etc. Following the INVEST principle can help teams achieve success more consistently.
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!