A good technique much discussed in software development circles (and around our offices of late) is the “User Story.” It’s a simple but effective method aimed at capturing what a customer or user wants to achieve through their software — about getting to the business case. By having the user convey their wishes to the software provider in this manner, it is possible then to derive exactly what features they require and, perhaps more importantly, what benefit(s) they seek to achieve.
The idea, as a recent article produced by a company called Rally Software Development denotes, is to “provide context.” It helps your consulting partner to understand your real, underlying need and thus better enables them to implement the functionality that you, the user, have in mind. It’s particularly useful for tasks like creating reports, modifying workflows and executing software modifications.
The User Story typically features a Who, What and Why. (Our image today, a Dilbert cartoon, is only one way of looking at user stories, thankfully.)
The Who of course refers to ‘who’ wants the desired functionality. The idea is describe which customer or user benefits. You seek a richer understanding of the person’s needs and motivations, so you want to keep this part as specific as possible.
The What specifies the need, feature or functionality that the ‘Who’ desires. This is what needs to be built into the software or report or process fix to be provided. It needs to be crystal clear – often involving a fair amount of questioning and back-and-forth dialog – in order to ensure that the team knows what to build. When software modifications or reports are the basis for the What, it is particularly important to convey all the necessary details.
The Why specifies the underlying ‘value’ to the Who. It’s the reason for the deliverable in the first place. Why do you want the software or process to work this way? The Why often gives the story, or as the folks at Rally Software point out, “its richness.” It helps the team design the solution that meets the real needs of the user. Also, in today’s more ‘agile’ development arena, the Why keeps the value front and center. It is a way of restating and reemphasizing, in an ongoing manner, the business case that brings the actual value or ROI to the customer.
In fact, if you cannot find a Why in your User Story, you might have a story with no value.
In our next (and concluding) post on User Stories, we’ll give a real-world example of a User Story and look at a few cues that help ensure a successful outcome. Stay tuned…