User stories: deceptive simplicity
I've seen a number of Agile adopters who thought that switching from traditional requirements specifications to user stories can make their life easier in some magical way.
- Come on! User stories ARE simple. Write three lines of plain text and off you go!
Yes, sometimes that's a fine way to go - if you have deep understanding of the subject in question, and your vision matches the customer's vision. But this requires having a long and successful history of communication and collaboration with your customer, which a quite rare situation. Your customer should be technical-savvy to understand the decisions you make, or he has to trust your decisions completely. On the other hand, YOU have to have a deep understanding of the customer's business, you have to predict his needs - and that's not easy to do.
If you don't have this kind of relationship, you risk hearing from your customer something along the lines: "That's NOT what I wanted!" after you implement the story.
That's when you remember to include acceptance tests, UI prototypes and other aids along with the story. No more simple three-liners, huh?!
In other words, thinking that replacing old-fashioned specs with users stories means less work can be wrong. The user stories can make you work more, not less. Instead of preparing formal paperwork, you can be forced to spend more time actually speaking with a customer, trying to understand his real needs and putting them into a human-readable format.
Nevertheless, IMHO, having a quality, human-readable user-story beats preparing tons of formal documentation which no one but engineers can read. If the customer can understand plain-language user stories, then he can manage them: make amendments, prioritize them et cetera. It is much harder for him to do all this stuff when he is presented with the formal documentation (which non-technical people have trouble dealing with).
And that's the true advantage of user stories, not the illusion of saving time or effort.
- Come on! User stories ARE simple. Write three lines of plain text and off you go!
Yes, sometimes that's a fine way to go - if you have deep understanding of the subject in question, and your vision matches the customer's vision. But this requires having a long and successful history of communication and collaboration with your customer, which a quite rare situation. Your customer should be technical-savvy to understand the decisions you make, or he has to trust your decisions completely. On the other hand, YOU have to have a deep understanding of the customer's business, you have to predict his needs - and that's not easy to do.
If you don't have this kind of relationship, you risk hearing from your customer something along the lines: "That's NOT what I wanted!" after you implement the story.
That's when you remember to include acceptance tests, UI prototypes and other aids along with the story. No more simple three-liners, huh?!
In other words, thinking that replacing old-fashioned specs with users stories means less work can be wrong. The user stories can make you work more, not less. Instead of preparing formal paperwork, you can be forced to spend more time actually speaking with a customer, trying to understand his real needs and putting them into a human-readable format.
Nevertheless, IMHO, having a quality, human-readable user-story beats preparing tons of formal documentation which no one but engineers can read. If the customer can understand plain-language user stories, then he can manage them: make amendments, prioritize them et cetera. It is much harder for him to do all this stuff when he is presented with the formal documentation (which non-technical people have trouble dealing with).
And that's the true advantage of user stories, not the illusion of saving time or effort.
Comments
Post a Comment