Enquiries: +44 (0)20 7692 4832

Agile Business Change Blog Thoughts on Agile Strategic Business Change and Agile Delivery

In a previous blog I raised some objections to the acronym INVEST, a widely-used definition of what a good story should be. In this post I introduce the alternative acronym that we use: VISIT.  More importantly though, I provide a concrete and rigorous definition of a story.

The acronym VISIT stands for:

  • Valuable
  • Incremental
  • Small (as small as possible)
  • Independent (as independent as possible)
  • Testable

In fact, the overriding statement is that stories should be Incremental: Testable and Valuable are part of the test for whether a story is truly Incremental.

Here is what we mean by "Incremental": take a system which is complete and self-consistent with a certain amount of value; after playing a story you should have a new system which is complete and self-consistent, which has more value. A story can be thought of as a state change, providing an Increment of capability. The words Increment and Story can be seen as synonymous.

Because a story results in a complete system it therefore follows that the story is Testable using end-user functionality.

When asking whether the new system has "more value" we are explicitly talking about external value, ie deployed, usable value. This is in contrast to internal value, which might provide validation or learning, but is of no direct value to the end users.

So here is a clear, explicit definition: a story is an Incremental system improvement that is complete (Testable through end-user functionality) and adds external Value.

What about Independent and Small?

It is desirable that stories are Independent (because there more scope for prioritisation). It is not essential though. Increments are, by definition, going to build on each other, so that basic capability needs to be built before more advanced capability. One should certainly ask whether there is unnecessary dependency between stories and remove it.

It is also true that stories should be broken down into the smallest possible valid Increments before they are played. The break down and refinement of stories occurs throughout the project, so at any point in time some stories may not yet be as small possible.

The danger of having Small as a criteria is that stories are then broken down too far, so that they are no longer valid Increments. This leads to all kinds of confusion and bad practices. What happens when stories cannot be broken down small enough to be played within sprints? This will be the subject of the next blog.

How does VISIT compare with INVEST?

Valuable and Testable remain unchanged. Independent and Small have been retained, but as second class citizens. Negotiable and the Estimable have gone, and Incremental has been added. It can be argued that a key part of Estimable, that the story is concrete, is now captured more clearly by Incremental. Negotiable is more to do with the lifecycle of a story than whether it is a good story in itself.

As a final note, using the word Increment has caused some confusion with people aware of the Iterative vs Incremental debate. In the context that we are using it, an Incremental step change can equally be an addition of new capability or a refinement of existing capability.

"Story" blog post series
  1. What's in a Story? The problems with INVEST
  2. What's in a Story (Part 2)? VISIT - an alternative to INVEST [this post]
  3. The Search for Small. Avoid making stories too small

Comments

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.

James Yoxall's picture

I'm IndigoBlue's Process Director and spend most of my time working for our Agile Programme Management clients and working out how to apply Agile thinking in increasingly more complex situations.

WHAT WE'RE SAYING

14
MAY
Trust

 

While I was working with one of my clients a few years a go, I was given a book to read by the CEO.  "The Speed of Trust".  I read the book with a healthy dose of scepticism having read many management books in the past.  But this book resonated with the core principles of Agile for me.

ABOUT US OUR SERVICES SECTORS BLOG CONTACT
How We Work Our Philosophy Management Team Our Clients Case Studies Agile Change Strategy Building Agile Capability Agile Programme Delivery Financial Services Government Media Not for Profit Retail TrustSkyfall - or falling from the ...Building Eden - Or how to live...DevOps on Windows - Fun Times ...