Finding the assumptions in stories

My colleague J.K. has written an interesting blog post where he describes a slightly different approach that he’s been taking to writing stories to help move the business value in a story towards the beginning of the description and avoid detailing a solution in the ‘I want’ section of the story.

To summarise, J.K.’s current approach involves moving from the traditional story format of:

As I...
I want..
So that...

To the following:

As I... 
I want..
By...

I quite like this idea and I’ve noticed that even without using this story format technical solutions are sometimes described as the business requirement and we need to look beyond the ‘I want’ section of the story card to find the real value and locate assumptions which have led to the story being written in that way.

To give a recent example, a colleague and I picked up the following story:

As the business
I want a HTTP module to be included on the old site
So that I can redirect a small percentage of traffic to the new site

We assumed that other options for redirecting traffic must have already been analysed and written off in order for this to be the suggested solution so we initially started looking at how to implement it.

After a bit of investigation it became clear that this was going to be quite an invasive solution to the problem and would involve re-testing of the whole old site (since we would be making a change there) before it could be put into production. That would take 2 weeks.

Speaking with Toni and Ashok about the problem it became clear that it should be possible to control whether traffic was going to the old or new site by changing the configuration in our load balancer, Netscaler.

Discussing this further we found out that this had been tried previously and hadn’t quite worked out as expected which was why it hadn’t been considered as an option.

We spent some time talking through using Netscaler with the network team and agreed to try it out on a performance environment and see whether it would balance traffic in the way that we wanted which it did.

We still need to make sure that it works as expected in production but it was an interesting example of how solutions can be excluded based on prior experience even though they might still be useful to us.

I’ll certainly be more aware of noticing when a story details a solution and try and look for the actual requirement after this experience.

This entry was posted in agile. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

4 Responses to Finding the assumptions in stories

  1. Dave Millican says:

    I’m agreeing with Colin. This is obviously a developer story. I still think its okay for stories to come from the development team but they need to sell the steakholder on why it should be done. How does it benefit them? Once that is answered and it is prioritized, then they can work on the solution.

  2. Joey says:

    I tend to follow a different format to bring business value to the front..

    In order to…
    As a…
    I want to…

    This comes from Liz Keogh, a BDD practitioner
    http://sirenian.livejournal.com/47679.html

  3. Colin Jack says:

    Hrm, does introducing a new teminology really help here though. The truth is the business don’t care if you use an HTTP module or not, so I’d guess the real problem here is really that developers are writing the stories on their own?

  4. James Curran says:

    um.. Since you showed the story written the “bad” way,
    don’t you think you should include it rewritten the “right” way?

Leave a Reply