3 Key take outs for writing better user stories

As an Equinox IT Senior Consultant specialising in business analysis I do a great deal of client work with user stories. A couple of weeks ago I attended two of Gojko Adzic’s training courses in Auckland, including his ‘Getting more value out of your User Stories’ course. In this article I share my top three key take outs from that course.

1.Only collect inputs that lead to an output

As business analysts it is in our nature to cover every base and leave no stone unturned, and sometimes this leads us to include EVERYTHING in our requirements. However, in an Agile and Lean world we also need to be thinking about what is most important to deliver the required output and generate the least waste.

So when you are writing user stories be very conscious not to include every possible data item (or ‘input’) that we could collect from users unless these are important in delivering the output.

For example, imagine you’re starting a project to collect data on people’s preferences, so that you can send them targeted communications about movies and other activities that might interest them.

As soon as you start talking about people – there’s certain information you think you want, for example age and gender. But why do you want this? “Because it’s useful” I hear you respond – again I ask why? If an input is not required for a (preferably valuable) output, then it’s not required.

Realistically, gathering information about a person’s age and gender for movie and activity preferences is a lower value input than other inputs. For example, I know many people in their 30’s (both men and women) who love the Minions and other movie franchises aimed primarily at children – knowing that the person you’re targeting has a sense of humour, or doesn’t take themselves too seriously may be a more useful input to whether this movie type would appeal than age or gender.

Every input costs, including effort for requirements elicitation and definition, development, testing, collection from users and ongoing maintenance. Targeting your inputs to those that will be used to produce an output – identify your output’s up front and work towards them.

2. Only deliver outputs that lead to a desired outcome

Most projects have limited time and budget, therefore it’s important to concentrate on items that will lead to the realisation of a (preferably prioritised) outcome.

When you are writing user stories, you want to ensure that the outputs that the implemented stories will deliver contribute to the delivery of an outcome or business value that the organisation needs. This also minimises the waste from effort that might otherwise be spent on implementing user stories with outputs that are of no or lesser value, or may not even contribute to the outcome in question.

Continuing our previous example, building the ability to capture and report on peoples' past movie attendance frequency might appear to be a useful thing to include as a user story output. However, when the outcome you’re trying to achieve is to have useful data on a person’s preferences so that they will rely upon the suggestions contained in your communications, knowing how often they have been to the movies lately is unlikely to contribute to this outcome.

Understand the outcomes to be achieved and measure each proposed output against that outcome, to ensure that the user stories being created and subsequently the work being done is going to achieve the desired outcome.

3. Don’t shove every task into a user story

Most agile or iterative projects will have a backlog that can be prioritised. I’ve sat in many a prioritisation session frustrated that neither the business nor I can understand whether cleaning up the test server is more important than upgrading to the latest version of jQuery, let alone whether it’s more important than delivering the next piece of business functionality. To present these types of user stories to the business for them to decide whether they’re important, and then also decide how important these are against stories that deliver direct business value, is counter-productive.

You don’t have user stories on the board that dictate when you can check your emails, investigate quality issues and so on. These are hygiene tasks that keep the engine running. Once the team has agreed that they are required, they need to be done.

While you shouldn’t put these tasks into user stories, you’re still likely to want visibility of the tasks, the work that is needed and how long it will take, as these will take time away from the delivery of business focused user stories. One option is to set an allowance in your sprints for this type of work, so that it gets done, is not hidden, but is also limited so that it does not place undue pressure on the delivery team to deliver a full sprint’s work as well as the other tasks.

Better user stories

Better user stories are those that only collect the inputs that lead to a valuable output, where that output also leads to the desired outcome or business value that the organisation needs. Focusing on the outputs, with the inputs as a means to that end in your user stories will lead to less waste and greater business value from your Agile project.

Managing essential hygiene tasks outside of user stories is better for your product owner or business representatives, and by setting an allowance and limit on this work allows your team to deliver these tasks while also delivering the prioritised user stories that deliver direct value to the business.

Incidentally, these take outs can also be used outside of the Agile context. Particularly the first two points. Linking your inputs to your outputs and your outputs to outcomes is useful across all development methodologies.

You may also be interested in my article Using Specification by Example to become a better business analyst.

Kirsten Eriksen is a Senior Consultant specialising in business analysis, based in Equinox IT’s Wellington, New Zealand office.