Let Me Tell You A Story

When we work in an agile environment we become storytellers, we spend our days spinning yarns.

Rather than once upon a time its As a, I want, So that.

Rather than a beginning, a middle and an end its Given, When, Then.

But how do we tell a good story from a bad story, what makes a best-seller and how do we recognise a trashy novel.

The answer is for us to INVEST a bit of time and effort into our prose and follow a few simple rules.

Independent

One of the major elements that separates agile from more traditional approaches such as waterfall is an acceptance that the outlook is uncertain and we don't plan a long way into the future.

The only way this is possible is if the items on are backlog are independent of each other and can be put into any sequence.

You can't be flexible if the order your stories need to be delivered in is rigid, a backlog should be continually evolving and changing based on the perceived next priority and the next iteration of MVP.

Tightly coupled stories suggest that individually they aren't delivering any value meaning they are disguising the fact that you actually have one big story lurking on your backlog. This in turn indicates maybe you need to re-visit your definition of MVP, is it truly the minimum?

Negotiable

Following on from independence is negotiability, while a story is on the backlog everything should be up for negotiation.

That should include where the story sits on the backlog, what will be delivered and even whether or not the story is required any more.

Stories should capture the outcome not the detail therefore over time they are allowed to change if these outcomes need to change. Not all our good ideas are going to come at once, if someone has a brainwave nothing should get in the way of that value being delivered to the customer.

The point at which we are committed is when that story is in a sprint, at this point everyone needs to be happy that the story is delivering value and is achievable.

Valuable

Stories deliver value, value delivers happy customers.

A story that doesn't deliver value is a sub-task of something larger, this means it is unlikely to be independent or negotiable, we are sleep walking towards waterfall.

When creating stories we should be looking to create vertical slices of functionality with just enough of the layers underneath to deliver value.

Many of the may be tutting at this point, yes this is easier said than done. But we shouldn't lie to ourselves when putting stories on the backlog, sometimes deep down we know we are trying to do too much but we console ourselves that we are agile because we've broken the behemoth into multiple stories.

If something is a large amount of work then it remains a large amount of work no matter how you slice up the pie, completing a story should apply the ratchet effect and leave us better off than when we started not create a race to stabilise the product because we've started something that now we have to finish.

Estimable

We've talked a lot already about our plan being fluid but what information are we using when we re-arrange this plan?

One piece is the value that will be delivered but just as important is how much effort we think is required to deliver it.

If we understand what a story represents why would we not be able to estimate the effort, stories that cannot be estimated are generally too big, not well understood or both. Its also likely in this situation that the value being delivered to the customer is not clearly visible.

The value delivered to the customer needs to be evaluated next to effort required to deliver, we should be biased towards trying to find situations where large amounts of value are delivered by relatively little effort.

As your product evolves these situations will be harder to find but its a sliding scale, small amounts of value delivered by large amounts of effort are not desirable.

Small

A lot of what we're hinting at is that good stories are small stories.

Software development is not always a precise science, as stories get bigger we stretch our ability to accurately estimate the effort and foresee the potential roadblocks.

We are also pushing back the time when we actually deliver the value. The point of trying to fail fast is that the customer is the ultimate arbiter of whether something is valuable, failing slowly to deliver what may or may not turn out to bring value is the worse kind of waterfall.

Testable

So we've created a small independent story that delivers value, we've estimated it and based on all this negotiated its relative importance and committed to putting in a sprint.

How will we know when we've achieved what we set out to do?

Anyone that says when the code has been written doesn't understand how this works, working software isn't an act of faith, working software demonstrates its value by passing tests.

The value a story delivers shouldn't be intangible, it should be able to be made visible to everyone by tests that enable you to see the code doing its thing. If we aren't able to demonstrate the value what exactly is it we think we're delivering to the customer.

Waterfalls are a free flowing body of water, this fluidity isn't present in the methodology that bears its name. Agile is an attempt to break this rigidity and be capable of changing our minds whilst also still delivering timely value to our customers.

Badly written stories will kill this flexibility in a heartbeat, its possible to be doing perfect scrum whilst being totally un-agile.

Scrum is a tool, agile is a state of mind, don't write novels instead write punchy short stories where the customer lives happily ever after while still looking forward to the next instalment.