Divide responsibility for defining stories

One of the most common mistakes with user stories is to expect business stakeholders to fully define the scope. By doing this, delivery teams are effectively avoiding the responsibility (and the blame) for the ultimate business success of a solution. Although a case can be made for this approach, there is also a huge unwanted side-effect: people who are inexperienced in designing software products – business users – end up having the ultimate responsibility for product design. Unless business users have detailed knowledge of the technical constraints of your product, an insight into current IT trends and capabilities, and a solid understanding of your architectural choices, this is not a good idea. We could write a whole book on why this is a bad idea, but Anthony Ulwick beat us to it – read What Customers Want, if you need convincing. The end result is often technically suboptimal and buggy, with lots of technical debt because of bad design decisions. Delivery teams then have to waste a huge amount of time and money maintaining the overcomplicated solution.

The cause of this problem is a common misconception of the stakeholder role in agile delivery methods. The product owner or XP customer should be responsible for deciding what the team will work on. But deciding isn’t the same as defining, and this is where things go wrong! Getting business stakeholders to design solutions wasn’t the original intention of user stories – but many teams have fallen into this trap. If this situation sounds familiar, here’s an experiment that can help you fix it:

1. Get business stakeholders (sponsors, XP customer, product owners…) to specify only the ‘In order to…,’ and ‘As a …, ‘ parts of a user story
2. Get the delivery group (team) to propose several options for ‘I want…’
3. Both sides together evaluate the options and the business stakeholders decide which one will be implemented

We’ve done this experiment with teams that misunderstand stories, where their business users fully specify everything in a task management tool, expecting developers to just code without a discussion. Explicitly limiting the scope of what business users are allowed to specify can force a conversation. People can see the benefits of face-to-face discussions instead of handing information over using a task management tool. Conversation is a lot more difficult to skip when one side can’t write the whole story on their own. By making the delivery team come up with a solution, this technique can also help to provide a sense of ownership in the delivery team, and wake up their creative side.

Key benefits

The major benefit of this approach is that it forces both sides to have a conversation in order to decide on the actual solution. Delivery team members have to explain several options, and business stakeholders have to evaluate them, so this experiment can shake up teams where user stories normally come fully specified from the business side. The collaboration also puts the responsibility for solution design on the people who are good at designing solutions – the delivery team.

Because business stakeholders are constrained in specifying only the role and the business benefit of a user story, they typically think much harder about the impacts they want to cause instead of the features. That itself is a huge step towards preventing the user story stream of consciousness. The stories move from a generic unspecified value (‘in order to improve business’, or ‘in order to sell more’) to something very specific (‘in order to monitor inventory 50% faster’). This helps everyone to understand the dimension of the problem, and how much is worth spending on solving it, before you commit to a solution.

The third big benefit of this approach is that it forces both business stakeholders and delivery teams to evaluate several solutions, reinforcing the idea of flexible scope and moving analysis from ‘did we understand this correctly?’ to ‘what’s the best possible thing to do?’. Expecting to deal with several options also reinforces the idea that there isn’t much point in defining solutions in too much detail upfront.

How to make it work

Communicate clearly upfront that this is an experiment and that you want to run it for a while and then evaluate with everyone (business stakeholders and delivery team). This will make it easier to get buy-in. Running process changes as limited, reversible experiments is an effective way to avoid pushback and power-play politics. (For more on this, read Switch by Chip and Dan Heath).

Agree at the start that features are not allowed in the ‘In order to…’ part – this is an easy way to cheat the experiment. The ‘In order to…’ part shouldn’t say anything about what the software or the product does, only what the users will be able to do differently. An easy way to avoid the problem is to have a rule that it must specify a behaviour change, or enable or prevent a behaviour.

Try to propose at least three options for how the software might provide the value business users expect. Faced with only two options, people often just focus on choosing one of the presented alternatives. With more possibilities, the discussion tends to be focused on the constraints, and pros and cons of different ideas, and often inspires someone to propose a completely new, much better, solution.

Let business stakeholders also propose options in the discussion – but not before. Presenting different options and their constraints provides a better decision-making framework for evaluating ideas, including those that business sponsors have in their heads even before the meeting (and they always do have them). It’s absolutely fine to pick an option proposed by the business users, if they still think that’s the best solution at the end of the discussion.

The discussion should make everyone quickly understand that there is always more than one solution, and that the first idea is often not the best one. Once people are OK with this, and they see the benefits of collaboratively defining scope, you can relax the rules.