Archive for April, 2014

do your stories tell a story?

April 18, 2014 Leave a comment

I want to address a common anti-pattern that I see and suggest an alternative approach.  I’ve seen different styles of user stories, and though the sections differ by the needs of the team and the style of the BA/Product Owner, one common section that I see is the context (aka business context, narrative, etc).  This is usual a paragraph or two that is meant to show how the change  facilitated by the story will impact the user.  We’ll come back to that goal in a bit.

Anti-pattern:  A context that does nothing more than describe how the product will work after the story has been played.  The first reason I don’t like this is that there is already a section of the story whose responsibility is just that – the Acceptance Criteria.  Repeating the ACs in a paragraph is duplication of work and does not add any additional value.  The second reason is that it doesn’t achieve the goal of the context.

A Better Way:  We build software to aid us in activities that we need/want to do.  A story’s context is a chance to remind us how that story fits into the bigger picture and how it helps the user achieve a goal.  So let’s use the context to talk about just that…  what the user is trying to achieve.  Specifically we should focus on the benefit that capability will provide.  This allows us to bring the story to life.  It makes it real and allows everyone (stakeholders, the development team, even your grandmother) to think about why we need to play (or not play) that story.

I see four main benefits to using the context to tell a story.

  1. it aids in prioritization
  2. it allows the team to be creative in thinking of alternative solutions.
  3. it allows the team to know when they have done enough.
  4. it can be a lot of fun!

After all, there is a reason that we call them stories!

Let’s look at an example for a mobile application that connects riders with taxis

Example:  Changing the pick-up location for a taxi

As a Rider, I want to change the location of where the taxi will meet me, so that I can reduce the overall time it takes me to reach my destination

Context:  Late Larry was rushing home to pick up his son after work.  He knew he was later than usual, so he decided he would take an taxi from the station.  He requested the car to pick him up outside the station while still on the train.  When he exited the station he noticed that the car was stuck in traffic a few minutes away… coming from the direction he wanted to go.  Larry waited anxiously, glancing at his watch and realizing that he is going to be late again.  If only he could meet the car half way, he might just make it on time.

Acceptance Criteria:

Option to Change Meeting Point
Given I have connected with a taxi
And the taxi has not yet reached me
When I view the ride options
Then there is an option to change the meeting point

Select new location
Given the taxi has not yet reached me
And I am viewing the ride options
When I begin the process to change my meeting point
Then a map is displayed
And the taxi’s current location is displayed on the map
And my current location is displayed on the map
And I can indicate a new meeting point

Notify the driver
Given I am viewing the map to change the meeting point for a ride
When I select the new meeting point
Then the driver is informed of the new meeting point

Give it a try!  Add any good ones to the comments…

Categories: Agile, Business Value, Stories