User Stories
| I l @ ve RuBoard |
User StoriesAt the beginning of each iteration, the development team and the customer will meet to define the work to be completed in it, through the development of "user stories." A user story is a user experience or action on a Web site written on an index card ”for example, executing a keyword search. Each description is usually one to three sentences. Keep iteration stories in a highly visible area where there is room for daily standup meetings. In XP the customer develops the user stories; however, in Web XP stories are frequently created by programmers, designers, strategists; and project managers. This happens largely because the customer is unaware that a feature can be implemented or that a story is needed by the Web development process. Here are some examples of stories generated by the development team:
There are many recommendations for writing good stories. The ones we have found to be the most useful include those discussed in the following sections. Stories Should Be Written in a Language That the Customer UnderstandsDon't write stories that read like an advanced developer's guide to information architecture. Keep them simple, in plain words. If possible, if you have seen the feature on another Web site, reference its location. Stories Should Provide the Customer with Something TangibleDon't write stories that won't create anything once completed. At the end of the iteration, you will need to present a deliverable for every story that you agreed could be completed. Stories Should Take between One and Two Weeks to CompleteIdeally you should be able to complete several stories in an iteration, so make sure that the length of each story suits that time frame. Kent Beck recommends that stories take between one and five programming weeks. [2] We have shortened this to a maximum of two weeks, but it really is up to you. If a story is estimated to take longer, this is a sign that you should break it into smaller stories. If it is shorter than one week, try to combine it with another small story.
Stories Must Be TestableAt the end of every iteration, you must prove not only that the story has been completed but that it works. This is much easier for programming stories than for creative stories. Sometimes automated tests can be created and run by the customer at the end of an iteration. Sometimes the deliverable is more subjective , such as a mood board. In these cases the customer should agree up front that the deliverable alone is proof that the story has been completed. Once you have written a story, you will need to assess its priority, risk, type, and whether it involves creative, interface, or server-side development and dependencies. It is not recommended that stories be dependent on each other, but this is sometimes impossible to avoid in Web development. With all of the information collected, the next step is figuring out what can be done in one iteration. This will be a team effort, with input from both the developers and the customer. If you end up with stories that have dependencies, make sure that they are not scheduled in the same iteration. Once you have finalized which stories are scheduled for this iteration, save the rest for future iterations. We use a "story box" for each customer, in which we store all of the user stories created for a given project. The box is organized by iteration and allows us to easily flip through and see when stories were completed and what is left to schedule. There are many benefits of developing user stories, but our favorite is that they eliminate the need for thick requirements documents. Web customers rarely have the time or the patience to read through those documents anyway. Also, requirements change, and no one wants to go back and rewrite them. Stories are so much better because they are easy to create and can be reevaluated at each iteration.  |
| I l @ ve RuBoard |
EAN: 2147483647
Pages: 95