Cover photo by Robert Anasch on Unsplash

Disclaimer

Terms like “is”, “should”, “have to”, “do this” etc. are used throughout. All of them should be translated to “in my experience”, or longer “what I observed to be a helpful practice while working on real-world software projects”.

Introduction

A “story”, also known as a “user story” should be a

• concise
• sentence

describing

• a smallest possible
• functionality
• visible to a user of the software.

From idea to stories

I ask the customer what’s the next thing they want done. Customer answers: “Archiving. Users must be able to archive items.”

This is not a story. It’s just an idea. There are several stories here.

The software already has “items” implemented in a list on the software’s UI. Items can be added, edited, etc. Now we have to “archive” them. In further conversation with the customer, I found out that the UI has to have a new list, which shows only archived items.

Two obvious stories are:

• Archived item is not shown on the main list
• Archived item is shown on the archive list

“Archived” means “when the user executes an action to archive the item”. This can be a button on the UI which results in a call to the backend API. However, we don’t refer to the button in the story because it’s not important. UI/UX considerations don’t impact the functionality of the software, which is what we’re describing in stories.

As small as possible

The two obvious stories both start with the same action, but describe different outcomes. That’s why they are separate stories. The same thing happens when two different actions lead to the same outcome.

Don’t bundle stuff into stories:

• A & B => C
• D => E & F

Instead, slice ideas on very small stories:

• A => C
• B => C
• D => E
• D => F

Tying into existing stories

There is an additional not-so-obvious story here. Dealing with non-archived items is already implemented. This means there’s a story:

• Added item is shown on the main list

Now there should be a new story:

• Added item is not shown on the archive list

It’s obvious from the user’s standpoint, but software can do anything and computers like it when you specify everything in detail.

What’s next?

Here are some things we can do when we have stories that small:

Convert them to tests

I’m referring to automated acceptance tests. They ensure the code actually implements the stories, hint about shortcomings of the existing architecture and provide forever-correct documentation about how the code works.

Put them on a story map

Story maps enable us to prioritise across functionalities. If stories are small the prioritisation granularity is small as well, which gives us the ability to weed out more of the less important stuff and put it off for later.

Count them

Instead of estimating, we can count the stories as we implement them. This gives us a measure of how fast we’re producing the software.

We can plot those counts on a cumulative flow diagram. We can then project optimistic and pessimistic future story counts. This gives us a time interval hinting to the customer when the existing scope could be implemented. We can easily fix the deadline to project a scope interval which hints how many stories can be implemented before the deadline. This enables the customer to either cut scope or push the deadline.

More on story counting...