Among the many factors that determine the exit of a project, the quality of the requirements is certainly one of the most important.

Good user stories prevent misunderstandings, long clarification meetings, uncertainty on their completion and most importantly they reduce the gap between client’s expectations and reality.

The Definition of Ready and the Definition of Done already provide very clear measurables guidelines on what every story should include in its documentation and what are the conditions to consider it completed. However, they give a general definition that does not examine the qualities of the user stories or the relationship amongst all the stories in the backlog. Elements that are hardly measurable.

INVEST

One of the most interesting techniques I used to validate the backlog in its entirety lays in the motto INVEST in good stories, where INVEST is an acronym that resumes the qualities every user story should have:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable

Independent

It demands that every story describe a different aspect of the target system’s capability, so to allow for the maximum flexibility and the least constraints.

This is possibly one of the most difficult conditions to meet when writing user stories since it is not always clear whether or not two stories can be independent of each other.

Overlap is perhaps the most usual form of dependency. It occurs when multiple stories cover one or more capabilities and only partially. That leads to a high risk of including the same capability more than once or not including it at all.

Also forcing a delivery order is another high-impact dependency. If, for instance, there is a login capability in the backlog, it should not prevent the development of any story describing features for which login is necessary.

Dependencies cannot always be avoided: the capability of modifying a document implies that you already delivered the capability of creating one. However, the product owner is quite likely to prioritise the stories in that order already, so it will not represent an issue.

The third kind of dependency is the containment, occurring when stories are nested within each other. It might be a good strategy to understand large sets of stories in complex projects, but it conditions the delivery, imposing a particular sequence (i.a. the delivery of a whole theme before starting a new one).

Negotiable

Although we need the story to contain details, we do not need it to include all the details. Good user stories feature the amount of information required to prioritise them. The rest of the details is negotiable and must be negotiated after the team has agreed on the release plan.

Working out the details, on paper, before the delivery begins disrupts the purpose of using an Agile approach, but failing to negotiate the story will probably lead to a mismatch between expectations and implementation.

Valuable

One of the most innovative concepts introduced by Agile is the notion that delivering value is the ultimate goal of an Agile team. The same Agile Manifesto embeds this concept within the principle Responding to change over following a plan.

Every Definition of Done should include one important requirement: no story is done until it delivers value.

Estimable

Especially within a Scrum framework, the team must be able to estimate the stories as a way to commit to achieving some of them by the end of a sprint. Therefore, the stories must be compiled in such a way that the team can understand it. The negotiation is, by all means, part of the understanding process.

Small

Several Scrum experts already recommend making a story small enough as to comfortably fit within a single sprint (or half a Sprint according to some). Independently of the hard constraint represented by the end of the Sprint, smaller stories allow for a much better understanding of their content and, consequently, they are also easier to negotiate and ultimately estimate.

Testable

A story can be tested if it has been properly understood. Therefore, if you cannot test a story you should consider the possibility that the story is not clear enough, or maybe it is not delivering any value.

Adopting these rules not only to write new stories but also and especially to slice them into smaller pieces, might take some time, but it will pay back on the long run allowing you to write bullet-proof stories and improve your estimates.

Share This