 (http://tinyurl.com/2fydxm9) |
Great minds think alike, and fools seldom differ." implies that consensus is often the result of a coincidence or luck. If you look at the success rate of presentations, you might actually think that this is shear luck. So why is it you recall the exact words of a movie or a bedtime story book and not a single word from your last meeting?
Well, as Ben Kenobi tells us: “In my experience, there is no such thing as luck." . There is a method to this madness. Outside IT, people have been practicing the art of storytelling for centuries with good results to convey their message. This post explores the possible links and usage of the noble art in IT. |
User Stories: developing the story, creating your scenes
Instead of writing long specifications, Agile developers describe the functionality they develop as User Stories.
They are usually expressed as: “As a role, I want goal/desire so that benefit”
The benefit over traditional Use Cases and other requirements methods, is the conversation: this is used during the requirements discussion with the customer. And because it is in the language the business understands, it works better then dry technical documents. But the highest benefit is that it keeps the conversation going.
- Introduction to User Stories by Scott W. Ambler
- User Stories Applied by Mike Cohn
- Agile Story Telling
- Agile Story Development
Personas: defining your characters and giving them a context
While writing these user stories, finding a good understanding of the roles or actors is crucial. Graphical and User experience designers use the concept of Personas: A persona, first introduced by Alan Cooper, defines an archetypical user of a system, an example of the kind of person who would interact with it. The idea is that if you want to design effective software, then it needs to be designed for a specific person. Personas represent fictitious people which are based on your knowledge of real users.