Context is King

One thing I've learned from the time I've spent with customers gathering requirements, writing stories, and project planning, is the importance of framing everything in the context of business value. If you don't understand why a feature is desired before diving into a solution, you run the risk of delivering everything that was asked for and nothing of value.

I was recently told by a potential customer that their application was slow and asked what it would take to make it faster. After a cursory review of the code, it was apparent that there were several areas ripe for optimization. I pointed out the three largest bottlenecks I saw and gave a rough estimate of what would be involved in addressing them. The customers agreed that it looked like a good plan, but she seemed a little surprised, so I probed further.

"Why do you need the system to be faster?" I asked.

"It's a customer retention issue," she said. "Our users have stopped using the application because they say it's taking too long to get their work done."

I then asked what part of the application her users exercised most. After a little more back and forth, it became clear that the users spent the bulk of their time in the contact management section. This was definitely not the worst-performing part of the system, but since users spent most of their time there, their perception was that it was. That perception was more important than any profiling statistics I could possibly have gathered, and as it turned out, would potentially be easier to fix. A little bit of context allowed for large negotiation of scope.

I've often used the common "As a ..., I want ..., so that..." format for user stories, trying to emphasize the "so that" in order to draw out the real value. It's been fairly successful, but I'm always looking for new ways to focus the conversation on business value. One technique I'm eager to try is Michael Norton's suggestion of rearranging the story format to read "So that ..., as a..., I want..." in order to better emphasize its value. I like this a lot, and here's why:

A common definition for a user story is "A placeholder for a conversation." I'd much rather have that future conversation be about the implementation and detailed scope of a feature, and not a return to the drawing board because of a late realization that the feature provides no value. Putting things in the right context early can go a long way in that respect.