Story driven development

Not just business requirements in card form

User stories have two words that I often find disregarded when developing them — user and story.

Story

Stories read differently from business documents. They engage us emotionally and transport us into the world of the protagonists. We feel what they feel, we understand what they believe, and more importantly, we can think ahead in terms of the character.

As a User
I want to click a button
So that I can complete a purchase

I understand that there is no time to write a novel, and if we could write like George R.R. Martin we probably wouldn’t be slogging away writing user stories. But casting formulaic business requirements into the semblance of stories misses the point.

Does a user want to make a purchase? Does a user want to click a button? If a user wants to make a purchase, he probably doesn’t want to necessarily click a button. The user wants an effective way to conduct a transaction. Is that a button? Maybe a swipe?

As a user I want to purchase an item.

Do I want to purchase an item now? With one click? Do I want to purchase from a summary screen? Nowadays, we have best practices and we can guide the story.

As a user I want to be able to review the list of items I want to purchase, and then confirm that I want to purchase them.

Maybe we can do better.

As a user I want to be able to confirm my shopping choices before entering the purchasing transaction.

The above story outlines two ideas: that the user wants to confirm his/her choices. It says what the user wants without explicitly going to how and what. It allows the design team to start questioning, researching, and investigating. How would a user want to confirm? Visual list seems natural, but maybe voice for people who find it hard to read small print. What type of options do we want to provide? Quantity modifications, removing items from the list etc. So there is more value here but still some vagueness.

As a user I want to be able to visually see the items, their prices, and quantities before agreeing to enter the purchasing activity. I want to understand my total spending, and be able to modify, remove items, or modify quantities and see how that affects my total cost.

Here we define that we want to see the process visually and we provide reasons for the why — the ability to see total cost. Understanding that the user wants to see total cost, we can now understand that we would want to show shipping and taxes as well.

As a user I want to see the total amount I will be spending with a breakdown of how that cost is arrived at. I want to be able to modify the items in the list to be able to achieve the total cost that I am comfortable with.

Now the final piece.

John wants to see the total amount he will be spending and a breakdown of how that cost is computed. He wants to make changes to the items in his list by modifying the quantity he wants to purchase or removing one altogether. Having verified the items and the cost, John wants to proceed to purchasing the items.

User

In the last step we replaced “As a User” with John. John is a persona. By developing personas we are able to differentiate types of users. A 60 year old grandmother from rural Oklahoma may want a different experience from a 19 year old teenager enrolled in NYU. There is no magical “user” — there are only real people and by attempting to model real people we understand that the same functionality may be served by different stories for the same feature.

Nicole wants to quickly purchase the item she is looking at now. She does not want to add it to a cart as she is not shopping based on a list.

The same story can have even compound stories building on top of existing stories.

William wants to review the items like John but wants an additional confirmation of cost after selecting a payment method with an indicator as to when he will see the transaction appear in his bank account.

Engagement

This job of telling stories is not easy and it should not be done in isolation. It shouldn’t be done in a boardroom with a projector. It should be done in a circle like storytelling. We are telling the story of John and each one of us, developers, testers, product owners, brings a different aspect of his story to life. John becomes real in our minds — we build an emotional connection to his journey. We love building stuff for this person knowing that John will appreciate it.

The other part of stories is feedback. We need to track — if John is a persona based on some demographic assumptions about age and locality we need to see if the new feature responds to this group of people. John becomes an archtype for a group of users and we need to be able to reflect on how they feel about us. We did something nice for John — did John like it? We need to turn the schoolboy crush into a long term love story.

By focusing on story driven narratives we plunge our product into the lives of people and allow ourselves the opportunity to build rich, engaging, applications that add long term value to the customer. Agile is about engaging with the customer, not about rephrasing concepts using a new nomenclature.

Gratus is a Solution Architect who lives and works in Toronto — LinkedIn