Starting to adopt an agile mindset often means getting familiar with the task of writing good user stories. This can be quite a challenge for some product owners, especially for those new to this role. It becomes even more challenging when the rest of the team doesn’t know how to validate whether a user story is ‘good’.

This leads to discussions in which you hear:

  • “It’s ready but you can’t test it”
  • “The result of this story becomes visible after the next sprint”
  • “I have no idea how to test this story”

The INVEST methodology provides a great tool to check whether your user stories are truly agile, useful and leading to a value-adding, testable product increment.

“INVEST“ stands for:

Independent — Negotiable — Valuable — Estimable — Small — Testable


Each story should be able to exist on its own, without any dependencies with other user stories. They should especially be ‘order independent’. If this is not the case, setting priorities won’t be possible as some stories can only be implemented after others are done.

During a sprint, a team member should be able to pick any user story on the cork board, without having to worry about the right order.


A user story is the basis for a good team conversation, and can change based on the feedback or suggestions from the team. Both wording and actual purpose can change during this conversation, which typically takes place during the sprint planning meeting (scrum).The team might propose a different, less ambiguous, wording, or can ask that the user story is split into different, smaller ones.


The realization of a user story should always result in business value. Note that this is not automatically the same as customer value… Business value is defined as ‘any value for either the customer or the organisation” (e.g. an internal stakeholder). Typical value-increasing stories, without any direct benefits to the customer, are stories that:

  • increase internal efficiency
  • shorten internal lead times
  • reduce error rates (e.g. by automating processes etc)
  • reduce labor costs


A good user story can be estimated relatively easy. If it’s not estimable than it’s either too large or unclear. Splitting a user story into several smaller ones will make the individual user stories better estimable.

The main reasons to split a user story are:

  • To reduce complexity
  • To remove ambiguity or to make things more clear
  • Focussing on one goal, action and role per story


This one’s a bit related to the previous one, because smaller stories are easier and more accurately estimated.

The team should agree to a maximum complexity that a user story can have. If the user story is more complex than the agreed maximum complexity, then it’s probably not small enough.

For a 2-week sprint, a typical maximum complexity corresponds to about 3 days of development effort. In one of our latest projects, we used the numbers 1-2-4-8 to estimate relative complexity. A higher complexity wasn’t tolerated and resulted in reviewing and changing the story.


The acceptance criteria for a user story should be very clear, or the team will be building stuff which can not be verified. If the question ‘how will I know that the user story is completed’ can not be answered, then the user story should probably be re-worded, or thrashed.

When to use it

The INVEST methodology significantly increases the quality and usefulness of your user stories, and it provides a good framework and checklist to be used by:

  • The product owner during the creation of the product backlog
  • The team during the sprint planning meeting. The above checklist can be used by the team, right after the proclamation of the story by the product owner. Validating the story at this moment makes sure that no time is wasted during the estimation phase later on.
Tagged on: