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.
- it aids in prioritization
- it allows the team to be creative in thinking of alternative solutions.
- it allows the team to know when they have done enough.
- 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.
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…
There is a certain connotation with the word estimate. People think of cost and time. Think about the last time a mechanic fixed your car or you hired a painter to put a fresh coat of paint on the third floor windows. You are thinking about time and cost aren’t you? When we start thinking about a software project we are still estimating the cost and time, but of the project not the stories.We are doing ourselves a disservice when we say we estimate our stories.
We have been relatively sizing stories on projects for years. We are not estimating our stories. When we look at a group of stories it is pretty easy to compare them relatively to each other and have a good understanding of which ones are similar. The hard part is to predict how fast we will finish each story. It is the velocity at which we complete stories, combined with the total number of points, which allows us to estimate the project’s cost and length.
So why does it matter if we size our stories or estimate them?
As soon as we talk about estimating stories the client (and team) naturally start to think about the time it will take to complete a story and how much that story costs. This leads to people wanting to change the number of points associated to a story because “it is taking longer than the estimate”. Just because a story has taken longer than anticipated, does that mean its relative size is different to all the other stories? Maybe… but most often it is that our velocity is not what we initially thought it would be. Talking about the size of the story helps to focus on the velocity being the value that is different from expectations rather than the number of points on the story. With this mind set, we can move away from constantly updating the the number of points on every story and instead focus on improving our velocity by finding ways to be more effective and reduce waste.
One of my biggest frustrations on a project is when we have stories that capture a solution rather than a goal. Often this leads to long conversations with the business to drive out exactly what it is that should be built and hinders the creativity of the development team in finding the best solution for the problem. I’ve spent a lot of time over the last year and half thinking about this and trying out a solution to the problem and now after much encouragement from Mike & David I am finally blogging about it. This isn’t meant to be a silver bullet solution, but I hope it provokes some discussion and you find it interesting.
A few of us got talking while doing an inception early in 2009 that the ‘so that’ statement was often either repeating the requirement, was too general or was left off completely when capturing stories. This meant that we were missing the true goal of the business and lead to problems with scope and misunderstandings of what a story truly meant once we got into delivery.
Using an example of changing channels on a tv with a remote control, let’s look at some of the poorly written headlines you could have…
Headlines which repeat the requirement as the business value tend to be very difficult to prioritise because we don’t understand the benefit that they provide to the user.
As a viewer I want to change channels on the tv with my remote so that the I can use the remote to change channels.
Headlines which are vague cause debate over alternative solutions that may or may not solve the problem. Is using the remote really necessary to watch different channels?
As a viewer I want to change channels on the tv with my remote so that I can watch different channels.
Finally, in really bad cases you end up with no business value at all which are both difficult to identify alternative solutions for and to prioritise:
As a viewer I want to change channels on the tv with my remote control.
Of course there are always the times when a headline captures the true value of what the business is trying to achieve:
As a viewer I want to change channels on the tv with my remote control so that I can watch different channels without needing to be in reach of the television.
This story can be easily prioritised against other stories and alternative solutions identified, but there are still problems. The headline ends up being quite long winded and you may need to read it two or three times to grasp what we are aiming to achieve.
We played around with the idea of switching the so that and the I want but weren’t happy because it was very awkward when reading it. We got busy with the inception and the pressures of delivery overtook.
My next project was centered around helping the client learn to write good stories and develop their agile process. I had lots of time to think about what goes into a story and what is most important. My favourite question came back… how do we ensure that the true goal of the business is the most important thing captured in a headline. I came up with a potential solution, but didn’t teach it at the time because I hadn’t tried it myself. I’ve now used it successfully on my current client for almost a year and found that it has accomplished what I wanted and more.
The format that I use is:
As a (role) I want (business value) by (method/requirement)
This forces the writer to capture the value and be specific with what what the story is aiming to achieve. At first I found it quite challenging, but soon realised that the difficulty wasn’t because of the format, but that it was forcing me to have headlines which clearly stated the goal the business was trying to achieve. I wasn’t allowed to wimp out! The feedback that I have received from the developers on the team has been very positive and it has helped to ensure a common understanding with the business.Our remote control example now reads:
As a viewer I want to change channels without being in reach of the tv by using my remote control.
This states the same benefit to the viewer and solution as the ‘good’ headline above, but in a much clearer and natural statement. We can prioritise it easily and the team has the ability to think of alternative solutions. It also makes it very difficult to run into the ‘bad’ headlines from above.
Once I started using the format, I realised there was another big advantage. The business value is attached to the strongest words of the statement (‘I want’) and the method of delivering the business value is attached to the weaker word (‘By’). In the traditional I want/so that format it is the other way around. This makes a big difference in the conversations with the business when an alternative solution has been identified, but that is for a different post…