The essence of story slicing in agile development

Looking back through all the useful artefacts and references I’ve gathered over the years of being an agile software development practitioner, I found this:

http://www.agilelearninglabs.com/2013/05/new-quick-reference-guide-for-splitting-user-stories/

It is a really nice quick reference guide to slicing/splitting/narrowing/thinning/refining (whatever you want to call it — and there is some debate around the “right” terminology) user stories. There is more good stuff to find if you follow the link above.

People get very bogged down with this essential practice, but (like with many others in the agile development space) it is conceptually simple.

Overall, when doing agile software development, given our number one priority is to satisfy the customer with early and continuous delivery of valuable software, the question to keep asking over and over is:

“What is the simplest, quickest way to deliver some value to the customer?”

In order to answer that question, we can rephrase it as:

“What are some options for delivering value to a customer as soon as possible?”

THIS is the essence of story slicing — the WHY behind it.

NOT:

“What is the simplest, quickest way to deliver this story”.

These questions are subtly different in words, but very different in outcome.

For one, the former question(s) keeps us in the customer problem space — where we want to be. What is the customer trying to achieve — the enabler for them to solve their problem or meet their need? In order to answer this question, we will start uncovering options by slicing problems and capabilities (which good user stories should represent).

HINT — these options are NEVER something like “Build a website that lets them pay their bills!” — you’ve made the classic mistake of jumping into solution mode way too early. Slow down there, cowboy!

Secondly, a story is not something we implement — it is a continuous cycle of exploration, discovery, delivery and learning through cards, conversations and confirmations (CCC, or “the 3 C’s”). We learn what we will build through the story — we don’t build the story itself.

The latter question — “What is the simplest, quickest way to deliver this story” — does sound useful on the surface, and indeed it will be useful when we want to be in the solution implementation space of the CCC cycle of a story, which we don’t right now.

Why don’t we? If we are looking to deliver value incrementally, we only want to talk about implementation just-in-time (JIT) — when we have actually prioritised the capability we have decided to implement for the story, and are getting it ready for development in the next sprint/iteration — otherwise we are getting into solution mode prematurely, resulting in potentially wasted analysis time (which will need to be done again if/when the story rises to the top of the backlog), and a lack of focus on the highest value thing to deliver.

For example:

Story: “Enable customers to pay their bills online”

Asking the question: “What are some options for delivering to a customer the ability to pay bills online as soon as possible?” leads to uncovering customer-centric, independently implementable and valuable capability options such as “by BPAY, by credit card, by direct debit”. We can then judge and pick the simplest and quickest of the more precise options, and ask the same question again: “What are some options for delivering to a customer the ability to pay bills online using BPAY as soon as possible?”

If we don’t ask this explicit question and simply look to “slice the story” or discuss “how to deliver this story”, we may be drawn toward company-centric, solution implementation options such as “build a portal”, “build a website”, “build a mobile app”, “use Worldpay”, etc.

We want to defer the latter type of thinking until we have thoroughly explored the problem space through slicing a tree of increasingly precise options to deliver the top level valuable capability, and chosen the simplest, quickest option branch to zone in on.

Otherwise we immediately land in a world where we need to do a bunch of analysis to understand how to build the thing. There is complexity hidden behind innocent words like “customers”, “users”, “pay” and “bills”. There are inferred assumptions lurking around “the business” as to what the expected solution looks like:

“We’re building a fully fledged online banking platform (using x technology stack on y platforms) to serve all of the banking needs for individuals and businesses!”

Using the advice from the quick reference card above, we can slice the words “customers”, “pay” and “online” to be more specific. Perhaps, for now, we will enable only individuals to pay their bills online using BPAY rather than businesses. Perhaps, for now, “online” will just be a single-purpose webpage rather than a fully fledged online banking portal.

We know we’ve done a good job with slicing when a story option we end up with:

Enable individual customers to pay their bills online using BPAY

is a more precise (and independently valuable) way of delivering the top level capability:

Enable customers to pay their bills online

rather than it being one step in delivering a solution for the top level capability.

If ALL we do is enable individual customers to pay their bills online using BPAY, and NOTHING ELSE, we have delivered value, both to the customer and probably the business too.

Instead we often find ourselves in the latter scenario, either consciously or unconsciously, where we turn initiatives like “online banking” (or “enable customers to bank with us online”) into a project or program — prematurely jumping into the solution space, rather than slicing the problem space as described above, and taking branches one by one, small batch by small batch.

This is a shame, and avoiding this trap is the key to grasping what agile is and how to derive benefit from it (yes, slicing IS THAT important).

Instead, slice out all the options we can think of, pick one and start delivering value.

All the other options we uncover at different levels of the slicing tree — like paying bills using credit card, other capabilities around paying bills (different payment types, different customer types), other capabilities around online banking (making transfers, applying for mortgages, etc.), other capabilities outside of online banking which we are not even discussing here — we can defer, for later or never.

We can’t do everything at once anyway, so why not pick something valuable we can achieve in the next few weeks and focus on it? And then keep on asking the perpetual question:

“What is the simplest, quickest way to deliver some value to the customer?”