Geeks With Blogs
Robert's Blog ideas about design and development

I've tried Use Cases and seen them not work. The main reason? They are really heavy handed and developers hate updating them. Customers don't even want to see them. A manager telling me to update the use cases or the functional spec is akin in my mind to someone I don't know telling me to take my medicine. I am one of those annoying developers who is going to ask, "Why am I doing this?" And bad news, if you don't have a good answer, I am going to look at you cross-eyed.

Developers in general (especially Agile Developers) try to remove the pain of really dull or repetitive tasks by stripping down the task to the bare minimum needed to complete the task or by automating it. Believe me, if developers could automate fishing for requirements, they would (an android that can ask those silly customers just what the heck they really need == geek love object).

There's a saying in Agile land, "Do the simplest thing that could possibly work". To me, in the context of getting requirements for a software project, that simplest thing that could possibly work is the User Story. There is a template for User Stories floating around out there that I believe is attributed to Mike Cohn that follows the form, "As a <type of user>, I want to <some action>, so that <motivation>." That's as simple as it gets. You've done some type of user role modeling hopefully to figure out what kind of interface to build (Web 2.0 shiny thing vs CLI). You know what they want to do with it, and more importantly, you know why they want to do it (whatever it is). Understanding this motivation for using the software allows the developer insight into the problem that actually needs solving. This is useful in the case where a story has been estimated and the estimate is not smiled upon. The developer can look at the motivation and suggest perhaps a simpler way of getting the same result.

User stories with estimation also force both the developer and the customer to think about decomposition. How can this be broken down into more manageable pieces? We've got this really pretty user story that took someone all day to write that we've estimated at three months, so what can I do to get the most valueable piece of this cake served first? Compound stories, stories that can be broken down into smaller stories, when given a high value by the customer can artificially inflate the value of the cruft parts of the story. Say for instance you have the following story, "As a job searcher, I want to be notified when a long running search errors out, so that I know to try again." Talking to the customer, they want to put up a toaster on the screen when a search errors out. They also want to make the windows start bar flash if the user has minimized the window. The also want to send an email,a tweet, and a text message just in case the searcher has left the computer. That's a pretty big request. We talk about breaking the different kinds of notification down into different stories. We find out that the toaster on the screen has a relatively high priority and all the other bits have a relatively low priority. So the story with all the bells and whistles notification (3 months to complete) gets broken down and we start work on the most important part first, the toaster (1 week to complete).

Like most other Agile best practices, User Stories need to be used in conjunction with something else, namely acceptance tests. You need a gauge to answer the question, "Is the customer going to like this or not?" without popping into their office every five or ten minutes and saying, "What about now?"

Now about those damn "The system shall..." statements. You hired a developer to do a job, and that job is to implement the application in the best way possible. If you really want that to happen, this kind of garbage shouldn't be anywhere in your documentation. If you are a manager and you really think you know what the best possible implementation for a specific problem is, you had better be bending code on the level of your developers at least half time, otherwise you don't have a leg to stand on. If those "The system shall..." statements are really that important to you, I want you to ask yourself the question, "Is it more important that I deliver business value to the customer, or is it more important that I complete an application exactly as it was planned on paper six or more months before any users got their hands on it."

Ironically enough, after writing that last bit, I read the section entitled "Too Many Details" that is in a catalog of story smells in User Stories Applied. It says, "Including too many details in a story is indicative of placing too much value on documentation and favoring it over conversation." I know that this is going to make managers uncomfortable, because functional specs and Use Cases are designed intentionally to be all-inclusive, to leave no stone unturned. You can leave no stone unturned without a record written of your stone turning in exhaustive detail. User Stories to me represent a kind of targeted documentation that is done after a converstation. A memory cue if you will. Customers don't care about how you implement security in your app, so why are you going to include that in artifacts you use to communicate with them. Bottom line is, if someone hacks the system you built for them and corrupts all their data, they are going to sue your butt no matter what was on a piece of paper you handed them. Developers and technical managers should be aware of non-functional requirements like security, memory management and disaster recovery and should work to achieve those goals, but they shouldn't consume the customer's valuable time talking about it. Those things are best saved for an in house conversation captured in some other place than where the functional requirements of the system are recorded.

I know some of you are asking the question, "But without specifying every aspect of the system, how do I keep the developers from going off on some crackpot coding crusade." My answer to that is the notion of never coding alone. As a developer, you insure the viability of your product my looking over everyone else's shoulder and actively encouraging others to look over your shoulder. I know it requires a thick skin. No one ever said going Agile was easy. It is a heck of a lot easier to stay Agile than it is to get there. This mutual code inspection can be done through peer programming, code review, both or etc. (maybe static code analysis if it is not misused). Now, a word of caution. "Criticize ideas, not people." I pulled that straight out of Practices of an Agile Developer. We are all sensitive, and none of us like having our mistakes shoved in our face. So if you want to keep your developers from burning you in effigy, make sure code review stays amicable. None of us like the blame game, it is counterproductive, so keep it out of the development shop. Let me go on to reassure you that code review and peer programming do eliminate those capricious mind wanderings of the artist-programmer, because I am one and my fellow developers keep my feet wired firmly to the floor. I have also had many occasions to reciprocate.

Posted on Thursday, July 24, 2008 11:29 AM Agile , User Stories | Back to top

Comments on this post: Why I am sold on User Stories.

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Robery Stackhouse | Powered by: