User Stories are at the heart of agile delivery, yet creating user stories is a hard skill to master. I think everyone working in an agile project has battled with stories either too big or too small, too technical or without business value. Fifty Quick Ideas to Improve your User Stories by Gojko Adzic and David Evans provides solutions to many of these issues. This book helps readers to be more agile, instead of doing agile. It challenges ideas like using numbers for estimations and using velocity for capacity planning or for measuring value.

Structure

The ideas are grouped into five categories: Creating stories, Planning with stories, Discussing stories, Splitting stories and Managing iterative delivery. Each chapter presents an idea succinctly by describing it, its key benefits and how to make it work. Almost all have concrete and practical examples based on experience. Also, every chapter begins with a descriptive image that contains the essence of the idea. This is useful for remembering what the chapter is all about.

Here is a brief summary of each category and some of the ideas presented in the book.

Creating stories

This section focuses on how to create good user stories. It provides some suggestions on how to improve the process in order to spot issues and how to gather the necessary information.

Tell stories, don’t write them

The focus should be on the discussions, not on writing down all the details in a tool. Creating user stories should be a collaborative effort focused on conversation and the entire team (technical and business people) should be apart of it. Too many times we focus on the physical format, instead of finding out why we need this new feature. This also underlines the fact that the team needs to understand the business reason behind a requirement. Many times user stories are written as solutions or workarounds, which undermines the team. A mature team should understand the problem domain so they are better fit to propose solutions.

Don’t worry too much about story format

A story should be a token for conversation. We shouldn’t try to fit all the user stories in a single format. This leads to fake user stories (“As an admin I wand to administer the application”). Instead use pictures, drawings, questions, anything that drives the conversation forward.

Describe the system change

It’s OK to deffer commitment to a solution until the business outcome is clear (the why). But the story should also contain how will the system change (the what) . This helps highlight the complexity of a user story and can help you split a larger story. You can start doing this by adding a new clause to the story template – “Instead of..”.

Evaluate zone of control and sphere of influence

The zone of control contains the things that we can change. The sphere of influence contains things that we can’t change on our own, but are influenced by us. The need of a user story should be in the sphere of influence of the team, while the deliverable should be in the zone of control. This can help us spot fake or misleading stories.

Planning with Stories

This section helps you plan your work and structure the backlog. It tackles managing stakeholders, getting a big picture view and setting milestones.

Set deadlines for addressing major risks

Business might always pick quick wins over major risks, since this shows progress. This might lead to unsustainable work and no budget left to tackle the long term risk, which might make the product unusable. There should be a balance between learning (addressing major risks) and earning (getting business value). Alistair Cockburn summarized this as “Develop for business value – once the risks are down”.

Use hierarchical backlogs

Some backlogs are linear, containing only items of the same size. A backlog with 300 stories is hard to manage, so you get into story card hell. The solution to this is to have hierarchical backlogs, with at least four levels:

• business objectives or goals
• business changes or customer impacts
• software deliverables (e.g. epics)
• smaller software deliverables that can be released independently

Group stories by impact

This is one way you could use hierarchical backlogs. Impact maps have four tiers:

• goals – what problem are we trying to solve?
• actors – who can impact the outcome?
• impacts – what is the impact (behavior change) that we are looking to have?
• deliverables – these can be epics, user stories or tasks.

Create a user story map

Another way to avoid the linear backlog is to use user story maps. A story map is a grid with user journeys on the horizontal axis and software delivery milestones on the vertical axis. This helps team focus on why they are building the software and how it fits into the big picture.

Prioritise using purpose alignment

One problem with prioritisation is that the business often puts almost everything in the must have category. Using this technique, stakeholders need to answer two questions:

• is it mission critical?
• is it market differentiating?

By doing we can put user stories in one of four categories:

• Differentiating (mission critical and market differentiating). This is the category in which you should focus most of the effort.
• Parity (mission critical, but not market differentiating). These are good candidates for off the shelf solutions or outsourcing. A user story in this category should not be innovative. You should choose the simplest solution.
• Partner (market differentiating, but not mission critical). The organisation doesn’t have expertise to tackle items in this category. Partnering up with someone else who has extensive knowledge is a good solution.
• Who cares (neither market differentiating, nor mission critical)

By doing this, the business has two buckets for must haves: differentiating and parity. But each category is now approached differently.

Purpose alignment can usually be extracted from the value statement (“In order to..”) of an user story.

Discussing Stories

This section focuses on discussing user stories. It presents several ideas of how to improve collaboration, get the most out of conversations and how to spot possible issues and hidden assumptions.

Use low-tech for story conversations

Stories should be a token for conversation. But many time the focus is on the tool, be it Gherkin, Excel or Word. There are two problems with this approach. First, the tool will make you fit the discussion in a certain format (tables for Excel, Given, When, Then for Gherkin, bullet list for Word). The second problem is that the keyboard becomes a bottleneck. Only one person does the writing, while the others might lose focus.

A better approach for starting the discussion is a whiteboard. This will encourage collaboration and discussion. We should favor this approach even for remote teams. We can use a webcam and point at the whiteboard or divide (work in each location separately) then merge.

Imagine the demonstration

 One problem with sprint reviews is that they might not encourage feedback. Sometimes they are too technical or just don’t capture the stakeholder’s attention. This idea suggests to imagine the demonstration. When the team is discussing the acceptance criteria for a user story, ask the question: “How will we demonstrate this story?”. This way, the PO and other stakeholders have an opportunity to say how they would imagine it. This helps ensure that the team has a shared understanding of the story and its acceptance criteria.

Diverge and merge for story discussions

This is a simple yet powerful concept. The efficiency of a discussion in a team drops as the team gets bigger. Sometimes team end up with one person doing all the talking, which doesn’t encourage collaboration. For large teams, a better approach is to use diverge and merge cycles. In the diverge part, the audience is broken down into groups of 4 or 5 people. Each group works for 10-15 minutes and captures its own understanding of a user story. Then the groups merge and compare their work, paying attention to differences (in format, outcomes, open questions).

Group activities are a great way to get everyone involved. When one person explains the user story, it might make sense. But when you are forced to think about scenarios, you’ll have a better understanding of the story. We’ve tried this idea in our team and it was a great success. It fleshed out some misunderstandings that the team had and helped the team better understand the problem.

Measure alignment using feedback exercise

Sometimes story discussion stop when there are no more questions. This might be tricky when the team doesn’t know what questions to ask. A better idea is to measure alignment using feedback exercises. Someone in the team comes up with a more difficult scenario and asks the team what are the outcomes. Then each one writes down their answer and if the entire groups agrees, it means the team is aligned . This is a good way to measure shared understanding.

Divide responsibility for defining stories

Sometimes the team expects the business stakeholders to come up with the whole story. The problem with this approach is that they aren’t always the best people to design the solution. One solution could be to get the business people to specify the value proposition (“In order too…”) and the role (“As as…”). The team should then come up with several options for the feature (“I want”). Then everyone evaluates the options and the business stakeholders chose the best solution. Again, the focus here is on conversation, since everyone has to discuss the pros and cons of different solution. This can also help ensure that the solution is not a workaround.

Splitting Stories

This part contains ideas for splitting large and complex user stories. There is an emphasis on delivering stories that provide real business values. The ideas in this section are ordered, favoring the first over the last.

Forget the walking skeleton – put it on crutches

Most of us are familiar with the walking skeleton. This idea goes a step further – deliver the UI first, using a very simple architecture. This way users get value early and you can validate your idea. After you’ve proved the product is viable, you can work to bring the product on the target architecture, with minimal change to the UI.

Narrow down the customer segment

At the start of many projects, most features are must haves. Unfortunately, this hinders incremental delivery, because you need a large chunk of the product to be in place in order to provide value. One options in such cases is to narrow down the customer segment. Instead of giving everyone 2%, give 2% of users everything they need.

Split by examples of usefulness

Another potential issue with story splitting is when teams split work in technical deliverables and then they start looking for pieces that would bring business value. Many times the outcome is either technical stories or stories that can’t be released independently. One potential solution is to look the other way around. First, split the work in deliverables that provide value. Then look for chunks with reduced technical complexity (e.g. reuse part of the old system or need to provide just a part of the workflow).

Start with dummy, then move to dynamic

This idea builds on the fact that most of the value of software is in the outputs, not in the inputs. But many products start with input screens that just store data, without doing anything with it. Another approach would be to first hardcode the input and focus on the output. This is best fit for reference data (i.e. countries, currencies, etc.) that change infrequently.

Simplify outputs

If after simplifying inputs, the story is still too big, you could try to simplify outputs:

• start with just one output format
• make the output transient first, persist it later
• store insecurely first, secure it and encrypt it later
• cut outputs at different boundaries: persist the data in files first, store in the data warehouse later

Extract basic utility

When a business process has to be almost entirely implemented in order to provide value, one option would be to give users basic utility instead if usability. This usually involves semi automated process and manual data entry which could lead to data inconsistency. Because of these caveats, this solution is better fit for internal IT projects, since it’s easier to involve users in story discussions.

Managing Iterative Delivery

This section helps readers deal with long term planning, capacity management, prioritisation and managing scope.

Don’t push everything into stories

This is a really simple piece of advice that is not always followed. We should not try to fit everything in a user story. There are many types of technical tasks that just aren’t a good candidate for stories. Prioritising such tasks isn’t useful, since the business doesn’t see the direct value in it. So usually they end up at the bottom of the backlog. A better approach would be to set some time aside every sprint for handling this type of work. This also ensure the team gets some slack time, in order to be able to handle interruptions

Avoid using numeric story sizes

Story sizes might be misleading when used for capacity management and long term planning. Number story sizes can lead to an eager commitment on scope and time and favoring predictability over delivering value. The numbers might also provide a false sense of accuracy. Numeric story sizes might result in tracking busy work over business value, since it’s the easier path to follow.

The authors also give some alternatives:

• select several reference stories
• use budgeting for long term planning
• manage capacity based on analysis time or number of stories

Estimate capacity based on rolling number of stories

Measuring capacity based on numeric story sizes might lead to people gaming the numbers. This isn’t intentional, but numeric story sizes lead to a pressure to commit to a certain velocity. It doesn’t matter how many story points you have delivered if you get lots of bugs that need to be tackled in future sprints. Also, velocity should be used only inside the team, it should not be used for cross team comparison.

In order for this technique to be successful, stories in an iteration should be of similar size.

Estimate capacity based on analysis time

Another idea for capacity management is to time box the refinement and take into sprint only refined stories. This works well when there is mostly business uncertainty. If the team needs to spend a lot of time to solve technical complexities, analysis time is not a good capacity indicator.

Pick impacts instead of prioritising stories

User stories usually don’t deliver business objectives on their own. This can lead to prioritisation done at the wrong level. One alternative approach is to prioritise impacts instead of stories. Since impacts are much more tied to business objectives, key business stakeholders will have an easier job when they need to prioritise. This can also make it easier to spot arbitrary changes that aren’t related to the highest priority impact. For this to work it’s crucial that the people doing the prioritisation are empowered (so probably no proxy product owners)

Throw stories away after they are delivered

Stories are a token for conversation. They shouldn’t be used as reference. After a story is delivered, the acceptance criteria should be restructured per business capabilities. This helps people understand the current behaviour, not the entire history of it. You can use tags to filter work in progress. (If you want to find out more about this, I’ve also blogged about how to organize specifications).

Biggest Takeaways

This book contained lot of new ideas for me. Some of them are context dependent, but many are wildly applicable. An overarching theme is that stories are a token for conversation. There are many ideas on how to improve the conversation, by focusing on collaboration, not trying to make everything fit a given format.

The third section, Discussing stories, contains ideas that are easy to put in practice. For example, we have tried diverge and merge in the team, and it proved to be a useful tool for getting the team on the same page. Also measuring alignment with feedback exercises helps actually measure shared understanding.

If you’re tackling big user stories, make sure to read the forth section. There are a bunch of good ideas on how to split stories, while making sure they still have business value. The examples in this section also helped explain the ideas. The authors talk about building MindMup and some of the challenges they faced and how they split big or complex stories. I must admit I was surprised by how creative some of the solutions were. They definitely showed us how to deliver business agility.

The ideas on managing iterative delivery are also interesting, but might be harder to put in practice. The authors talk against using numeric story sizes, velocity for capacity management and other very common practices in agile projects. The good thing that they do give alternatives that, although might be hard work at first, make a lot of sense.

Conclusion

This is the second book I’ve read from the Fifty Quick Ideas book series. It delivered what I came to expect: 50 quick ideas, some well known, but some quite novel (at least for me). The chapters are small, independent and easy to read, so you can just jump right in and read one. This book should be treated as a reference book and you can come back to it when you’re trying to solve a specific problem.