Better Agile Stories by Embracing the Kanban Ace Way of Simplicity

Let’s Go Back to Basics

In the late 1990s Kent Beck and the people behind Extreme Programming realized that large software projects did not need extensive, detailed documentation to communicate the needs of the users to the development team. Instead of investing considerable time and effort on documentation they came up with this idea:

-Write a minimal but useful description of what the software should do. The description should fit a standard index card! Even more they argued that anyone could write a story, business users could do it to explain what they wanted, and also the development team could do similarly to describe their technical efforts associated with building software.

-Regarding how business users could write stories Kent Beck said: “Business writes a story describing something the system needs to do. The stories are written on index cards, with a name and a short paragraph describing the purpose of the story.” ^{[Kent Beck, Extreme Programming Explained, 1st Edition, p. 90]}

Since then however stories have become increasingly complex, some users, and even developers sometimes feel intimidated about writing them! What is going on, how did this happen? It was simply a case of forgetting the real reason for stories: clear, brief communication.

On this subject I asked Kent Beck himself on Twitter, and also Al Shalloway a respected leader in several Lean Agile methods. Below are his responses to our conversation on June this year:

Training Wheels Considered Harmful

Who hasn’t seen a 5 or 7 year old learning to ride a bicycle for the first time. In the old days you would have your father, mother or a good friend of the family spending some hours teaching you the basics, and giving you confidence. Balancing a bicycle and keeping it moving is not as easy as it seems, but most kids within a few hours learned, and later enjoyed the enhanced freedom that a bicycle represents.

I remember myself this learning process, and how at one time my uncle let go of the bike and suddenly I was pedaling on my own, feeling the breeze in my cheeks and with a wide smile on my face. Good times!

These days however parents are very afraid of their children, and provide training wheels for the bicycle to always keep balance regardless of the mistakes of their kids. This might sound like a good idea, but ultimately unless those training wheels are removed quickly, they can become a hindrance to the joy of riding a bicycle.

Exactly the same thing happened with stories, the people at a company called Connextra came up with a formula to write a story; if you’ve taken an official Scrum course it is quite likely that you were taught to use this template:

As a <role> I want <goal> so that <effect>

An actual example of an early card by Connextra is also seen below, please read it. Did you notice how forced and unnatural the template feels? Now granted the template acts as a training wheel the writer won’t forget he has to explain what is his goal, who is expecting this goal to be made, and the reason behind it. However this was never the intention of writing a story! Stories were meant to be natural ways to communicate between users, developers, and the people in a software team.

Here is one more example that will feel more familiar to today’s mobile generation:

As an Apple Maps iPhone User I want to be able to see the road traffic on my screen by enabling a button in my map screen, so that I would be able to avoid traffic and arrive faster to my planned destination.

You could argue that this unusual sounding, wordy story is useful, but I would reply that is actually more trouble than it’s worth, it is a typical case of a harmful training wheel. Why?

-This unusual format makes users, developers and people in a team afraid of writing a story! I am not kidding, I have actually had developers tell me they were afraid of writing a story wrong and then being ridiculed by a team mate. The ones doing the ridiculing or criticism are not even guilty of this, since many times they have been taught that any other way to write a story is wrong; this is most unfortunate, and not true. Stories are meant to communicate, not to follow a template.

-In addition using this format demands that the person follows it every time, like a clutch, instead of concentrating on expressing what needs to be done.

-Moreover this type of stories lend themselves to complexity, and verbosity.

-Finally this template makes it hard to read and understand stories by people outside the team, and even by the team itself. Why? Because it is not normal speech, it requires a mental effort to translate those words into regular ideas we can follow.

The Better Way to Write A Story

Think about the story I shared a minute ago:

As an Apple Maps iPhone User I want to be able to see the road traffic on my screen by enabling a button in my map screen, so that I would be able to avoid traffic and arrive faster to my planned destination.

Could you express, communicate, tell this same idea with more clarity and brevity? I am sure you could! Let’s give it a try, let’s take the training wheels off! This is the Kanban Ace Way: elegance and simplicity! Here goes our first try:

Create a button to enable the road traffic feature in iOS Apple Maps

Is that easier to read? Has the basic information been communicated? Yes! But how about the “so that I would be able to avoid traffic and arrive faster to my planned destination” part, did we ignore it? No! It is part of the context, it would be a waste to explain it again, and further more it does not matter the whole team know this is why we are doing this feature in the first place! Can we do better, can we simplify it even more? A bit more yes:

Create a button to display live traffic in iOS Apple Maps

Is it better? Yes! Why? Because it communicates better! That is the whole objective of writing a user story: to properly communicate your intentions to your audience.

So next time you are about to write a Story whether you are a user, a marketing manager, a Product Owner, a business manager, a developer, a project manager, a ScrumMaster, a QA Analyst, a designer: dare to communicate better, embrace the spirit of a story!

It’s time we go back to the roots of story writing, and since many have forgotten this type of clear, well communicated, brief story we wanted to give it a name: Ace Stories! Use them in your Kanban Ace boards, your Scrum boards, your product backlog, place them wherever you want!

To remind you what we explained today, and summarize it in a useful way with my co-founder Annita from AgileLion we prepared this useful checklist to guide you while you write your next Ace Story:

Finally it is worth mentioning that some stories may need supporting material like screenshots, UI mockups, flow diagrams etc. In the old days these would be provided in folders to the team members, nowadays they are usually attachments on an electronic card. If you need to use them please do,  but never forget the purpose: to communicate, so keep them brief, and to the point.

Now that you know all about stories: have fun, communicate better, write some Ace Stories!