Cover photo by Robert Anasch on Unsplash
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”.
A “story”, also known as a “user story” should be a
- a smallest possible
- visible to a user of the software.
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.
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
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.
Here are some things we can do when we have stories that small:
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.
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.