The “User story” or “use case” is a powerful tool for designing software. You pick a user, or “actor”, with a specific goal, and you diagram the process / workflow by which the user employs your system to accomplish the goal. Many of the projects that I see do not use this tool effectively, and as a result end up lengthening development cycles. Here is a list of issues, and fixes, that will make your stories more useful.

Generic user: This is the single most damaging user story mistake. You define an imaginary user with very broad needs, a “scientist” or a “mother”. You run into two problems that kill your ability to release software early and often. First, this generic user has a very broad set of needs. You end up looking at a huge number of features. Second, you can't actually call this user and ask specific questions - “red or blue?”, “do we need a lookup here?”. So, you don't get any of the details that you will need for implementation. When you diagram a user story, you should have a specific user in mind. This user only has a small number of specific requirements, and this user can answer detailed questions.

One demanding primary or reference user:  You can go too far and pick one user. This causes delays because this one user may have some one particular feature they really really want, even if it is irrelevant for most other users, and hard to build. They probably volunteered to be the reference user because they have an agenda. It pays to shop around and find less demanding users for your early releases.

Unfamiliar user: Software design is most effective when you are designing software for yourself. The user stories in this case are easy to get, accurate, and nuanced. A high proportion of really good software is built by people for their own needs. If you find yourself building software for users that you don't understand, you have a difficult problem. You can learn a huge amount from interviews with the intended users, but you will miss some things that will only come out when they test the prototype. I suggest two maneuvers in this case. First, you should make yourself into the user by walking through the process yourself. You will be like the hotel company CEO that takes a day a year to work the reservation desk, and ends up leading a rebuild of the entire reservation system. How many times have we heard that story? One way to get started is with a paper trail. I like to collect all of the pieces of paper that go into or come out of a business process, and pin them into a storyboard. You find a lot of data structures that way, and some workflow. Second, you need to partition your user base and find users that will take early alpha and beta releases. Your user stories will come more by feedback than by initial specification, so getting releases in front of external users becomes more important.

Non-user features:  The user story concept isn't very useful when you are working on features that users don't see: infrastructure, architecture, middleware, administration, etc. You can make it more useful in these cases by remembering two things:

• System administrators and developers are users too. They have user stories.

• If you really want to be agile, you build the underlying infrastructure As Late As Possible. You get releases to users faster, and you save yourself a lot of work in the cases where you find you don't end up needing the infrastructure. So, there is an argument to build the minimum amount of stuff that supports a visible user workflow.

Vague stories: Vague user stories without a specific user or actual example task will not give you the details that you need to do an implementation. You aren't doing any damage with them, but you are wasting your time, because you aren't learning very much.

Textual stories: If you have been in software development business long enough, you will eventually encounter a specification that has been built with use cases and formal requirements based on something like the Rational Unified Process. The first encounter is very impressive. It drops onto the table with a loud THUD, 400 pages of printouts. In some ways, this is a very useful document, filled with details that will help the developers go forward. However, it incomprehensible to the human brain. It has long lists of labeled requirements and step by step processes. You cannot absorb information in this format, and you cannot explain it to your users and project sponsors. It fails the first purpose of a user story, which is to get feedback from the subject of the story. So, you end up getting diminished benefit from the (expensive) planning process, since the user will ignore the specification and instead provide feedback only after seeing the prototype.

The solution: Make pictures, storyboards, and not text. Everyone will understand the storyboard. A storyboard is simple, even simpler than a flowchart. It's basically a flowchart with only the components that a user will see. It shows screens that the user will encounter while working with the system, and links that represent transitions between screens. It can be converted directly to a mockup. You can skip most of the text and write it in later as ticket detail and comments.