User Stories: What Should We Test?

Wednesday, 7 May, 2014

During a recent training course, I was asked a great question. “Should the acceptance criteria on a user story reflect acceptance of the “I want to…” or the “So that”?

As I paused for thought, my first reaction was the latter. My instinct led me to believe that the acid test is the business value has been delivered, or some resultant benefit can be identified. This has the benefit of giving the team more freedom to explore various solutions to solve the problem in hand. 

In my training classes, I ask the class to write a user stories for delivering “a cup of tea”. An example of a frequent response to this exercise is:

“As a thirsty person I want a cup of tea so that I can quench my thirst”.

This is a great example to debrief during the class for number of reasons. Firstly, user stories should promote conversations around problems, before solutions. If the benefit to a thirsty person is having their thirst quenched, then tea may not be the best (cheapest, simplest) solution. Cold water, or a soft drink may suffice.

Equally, the “user” here is equally important to query.  A ‘thirsty person’ will be looking for different benefits than a ‘tea connoisseur’ for example.

But how can you test thirst quenching successfully? Is there a risk that the team could solves the problem, but isn’t the right solution for the customer or the product. I think that is a risk. I believe teams should have freedom to discuss various solutions, but that discussion should diverge on an outcome agreed by both team and Product Owner, as part of the grooming/refining process. 

As a result of this great question, I have tried to consolidate my thinking into some simple tips for scrum teams to use in preparing stories ‘ready’ for sprint planning:

1) Start with WHO and WHY first. A product owner should be able to do this in isolation, and present this to the team.

“As a thirsty person, I want …. so that I can quench my thirst” 

2) Discuss the WHAT. This has to be a collaborative effort between team and Product Owner. There may be various options, designs, solutions, and estimates in play.

“As a thirsty person, I want a cold beer so that I can quench my thirst"

3) Then write and agree on acceptance criteria based on the proposed solution. This allows the team to nail down more testable criteria that will deliver the benefit required. Again, another collaborative negotiation between team and Product Owner.

Is the beer served between 4-8 degrees celsuis?

Is the beer served in a glass?

Is the amount of beer between 250ml-350ml?

Is the beer between 4% - 5% alcohol?

I think can get accept more uncertainty in potential solutions and acceptance criteria further down the backlog, so the rule of common sense applies on applying this to larger, less important backlog items.Whilst there is certainly no precise science to writing a user story, my opinion is there are good tactics you can apply to maximizing their benefit within a team.  

Just remember - “there is no perfect user story”.