Estimating StoriesPurposeThe ability to estimate how long a story will take is one of the keys to being able to plan your project. The purpose of this exercise was to learn how to estimate a user story. DescriptionWe used the user stories from the previous exercise in this exercise too. The participants were given 45 minutes to estimate all the stories. This gave them a little more than one minute per story. EventsBy this time the participants were used to the chaos. Most of them just started doing the estimates, although they did have questions about what kinds of units they needed to use. We told them they could use any units that they wanted. At the end of the time limit, all the groups had an estimate for how long they thought the application would take to implement. The estimates had a fairly large range, although all the groups were fairly certain that their estimates were correct, plus or minus 10%. Just as in the previous exercise, where groups had difficulty in writing acceptance tests for certain stories, the same stories were hard to test. In both exercises, the reason for the difficulty tended to be that the story was too large or too vague. |
Writing StoriesPurposeThe purpose of this exercise was to learn how to write user stories. DescriptionThe groups were given a one-page description of a course-scheduling application and were asked to write all the stories for this application. They were told to take turns, with one person at a time writing a story while the others asked questions and made sure the story was estimable and testable. The time limit for the exercise was 45 minutes. EventsThey wrote the stories just as if they knew how. By this time, the groups were much more relaxed and were even having fun. The exercises tend to build on one another—what you learn in one exercise is used and reinforced by the other exercises. In the previous exercises, the participants learned to think about acceptance testing and estimation. They also made a strong correlation between story "quality" and the ability to do acceptance testing and estimating. The participants knew the difference between a good story and a story that needs work. At the end of the time limit, the groups shared their stories. Different groups had very different ideas about the systems that they would be implementing. Some groups were writing the stories for a batch system. Some groups wrote stories for an interactive Web-deployed system. The one-page description we gave them didn't specify any type of user interface, so they were free to do anything they liked. |
ConclusionThis tutorial succeeded far beyond our expectations. When we came up with the proposal for this tutorial, we had a lot of uncertainty about how well it would work. We wanted people to learn about XP and have fun doing it. We thought the best way to accomplish those goals was in this format—actively trying to do some task, followed by a review of what worked and what did not. Fortunately, the participants agreed. Much of what made this an excellent tutorial was the enthusiastic participation we got from the students. Thanks to everyone for taking part so enthusiastically. |
Chapter 26. Continuous Learning—Joshua Kerievsky Copyright © 2003, Joshua Kerievsky, Industrial Logic, Inc. All rights reserved.
|
