Much has been written about creating user stories. There is a good User Story introduction on WikiPedia and Mike Cohn has written a well-known book on the subject called User Stories Applied: For Agile Software Development.
Despite all the literature, agile development teams often struggle with writing good stories. In this post, I’d like to draw attention to the issue of user stories that propose an implementation or solution rather than stating a problem, need or want.
This is a easy trap for software developers to fall into. In fact, anyone who has a good understanding of how software works might fall into these lines of thinking. Let’s consider the following examples.
1. As an expert buyer, I want the database to be indexed by part number so that I may quickly find the product I need.
The expert buyer is suggesting a solution to the problem of rapid information retrieval. There are many ways to design data stores. Indexing represents a means of finding information and there are many others. The implementation should be left to the developers.
2. As a financial analyst, I want the system to recognize interest functions such as NPV and IRR so that I don’t have to enter complex formulas.
Most financial analysts use Microsoft Excel to perform complex calculations. Excel contains Net Present Value and Internal Rate of Return functions. While those functions serve Excel well, there may be better ways of solving this analyst’s problem if he would clearly articulate it to the team.
3. As an experienced web designer, I want the software to support Cascading Style Sheets to make page formatting simpler.
CSS helps make webpage formatting clean and consistent. While CSS is a major component of good webpage design, it is not the simplest tool to master. It would be better to challenge the software developers to hide the complexity of CSS and present a simple user interface to the designer.
In each case above, we really want to know what the user is trying to accomplish. Then, we can determine the optimal way to help him or her get it done.
So the next time someone hands you a user story that suggests how to solve a problem, ask why. What is the user trying to do and why is he trying to do it? Be agile from the outset.