We just finished some Scrum Master training at work which certainly made me think differently about a number of things that I do. One of the things that hit me the most is about how we phrase our user stories. I'm sure most of your are familiar with the traditional layout of a user story.
As a [some user] I want [something] so that [benefit]
This captures the user of the story, the outcome from an interaction with the system and the benefit or value that the interaction is trying to achieve. For example you could have a story such as this.
As a student I want to be able to search for rooms to rent in my local area so that I can rent a local room
I'm not sure why that's the first thing that popped into my head. Must be related to all the graduate recruitment I've been working on recently. Anyway, the point that came up in the training earlier was that we can re-write this in the following way.
In order to rent a local room, as a student, I want to be able to search for rooms to rent in my local area.
This focusses the story around the business benefit rather than the actually user. It follows this format.
In order to [benefit], as a [role], I want [solution]
Now this is something we've actually tried in the past when we started experimenting with Gherkin syntax. Unfortunately I always missed a critical point. At it's core we're trying to provide a benefit to someone. In the original version that benefit is relegated to the last part of the story. This has the unfortuante side effect of making it seem like we're trying to achieve the solution rather than the benefit. Often in our user stories we prescribe a particular solution to provide that benefit to the user and then the teams estimate based on that solution when in fact there might be a whole variety of different ways we can provide that benefit to someone. Something that I'm certainly going to be trying to do is to remove as much of the implementation from the solution part of our story as possible. Obviously it isn't always going to be possible to do that but at least if we phrase our stories in this way it moves the focus of the story so that the team can focus on the benefit and always pitch in different solutions to get achieve that benefit. Sometimes those solutions might not give the best user experience but they might also allow us to get something in front of customers quickly that we can then build on if we find out that they even wanted us to solve that problem in the first place! For example we could pitch in the following variant on the user story I used earlier.
In order to rent a local room, as a student, I want to be able to see the positions of available rooms on a map
Both stories provide the benefit of allowing a student to select a room in a particular area but in radically different ways.