Adding value to stories
Tuesday 8 July 2008Over the last few days I have been looking at how epiGenesys uses stories and where we can make improvements that add value to provide a better resource for development. After much research on the web looking at how others use stories I have a few changes in mind.
Firstly, I plan to add more structure to our stories by replacing the open description field with a template. The intention is to make it easier to extract specific information which can be redisplayed in alternative formats better suited to other purposes. An example might be the extraction of a list of performance needs to be referenced when generating tests. The template will also encourage the capture of all the requested information.
I also plan to require the inclusion of information on the business value of a story. This will enable us to more effectively consider client objectives when planning and prioritising work. It should also encourage a stronger focus on developing business value rather than just developing functions. In addition, I am interested in the possibility of generating marketing information for an application (such as feature-benefit summaries) directly from stories. Thus the template I propose is:
In order to
<achieve a benefit / mitigate a risk / satisfy an obligation> (from a business perspective)
as a
<type(s) of user>
I want to
<perform a task>
and I require
<performance need(s)>
In addition, I plan to replace the testing information captured in our stories with structured operational requirements in the form of scenarios. These capture the outcome expected by the client from a piece of functionality for a set of contexts, and passing all the scenarios for a story indicates that business value has been delivered. The intention is that we can use this information to demonstrate progress and to assist with automation of client acceptance testing. The scenarios should also help with our planning; a large set of scenarios for a single story indicates that the story should be broken down into smaller stories so that progress can be demonstrated by the delivery of each. The template for this is:
Given
<context condition(s)> (do not specify anything that is not required, but do not assume anything that is required)
when
<event> (story user(s) attempt(s) story task)
then
<outcome expectation(s)> (if there are alternative outcomes then the context is ambiguous)
2 Responses to “Adding value to stories”
Good job Chris!
By Jon Rowe on Jul 8, 2008
Hey Chris
Interesting take on the story structure! I see you are putting the business value first, that’s something that’s been on my mind for a while. I think having this last can make it an incidental “oh, by the way, WHY do you need this?” rather than a fundamental “what are you aiming to achieve?”. I think I will start doing this your way from now on.
More unusual is attaching performance requirements to stories. I’ve seen this recorded as “constraint stories” but not rolled into the basic functionality stories. My suspicion in that most stories in most apps will not require this performance constraint section, but I guess it depends on your domain.
The GWT structure is very good at expressing system behaviour. I will say thought that having a large number of scenarios is not necessarily indicative of a story that is too broad; their may just be a lot of edge cases. I think having scenarios that describe wildly different contexts and outcomes is a better indicator, and probably having different Whens is the real killer. YMMV of course.
Post again when you’ve got a decent volume of stories and you’ve seen how it plays out! I’d be interested to know how you got on.
Ash
By Ashley Moran on Jul 12, 2008