Extreme Programming Installed Ch 4-6

User Stories

Extreme Programming Installed

Ron Jeffries, Ann Anderson, and Chet Hendrickson

Summary

Chapter 4 discusses User Stories. In XP the system is specified entirely through stories. In order to do this, we need to find out what the customer wants, and this is done through informal analysis, or in order words: we just ask the costumer and write it in blank cards (stories.) The book explains this process, and emphasizes how important it is to get comfortable with the cards, we should not be afraid of tearing them apart and writing better stories. At the end, the chapter gives a bunch of sample stories.

Chapter 5 is about Acceptance Tests. The book makes clear that we should always test before we ship, and ideally, we should test right after we program something. There is no more important feedback than early information on how well the program works. Test everything you want working in your program, and do it in an automated way. The chapter finishes by giving a few examples on different scenarios and how you could test them.

Chapter 6 is about Story Estimation. Not all stories are the same size so it is hard to estimate the pace of the project just by looking at how many we have. However, there are several things you can do. For example, you can estimate by comparing stories; often one story is just an elaboration of another one. We can achieve this by ranking stories with a point system, and then just assigning similar points to similar stories. At the beginning, however, there is no comparison to be made so the book explains how we could start assigning points based on the “perfect engineering weeks”. Those weeks where you program perfectly all day every day are a perfect engineering week. For example, if you feel you can do a story in one perfect week, then you would give it one point, and so on. An issue with this approach is when you haven’t done anything like the story you are trying to rank. The book explains how in this case you should do some experimenting in order to find out how much time that type of work could take you. Finally, the chapter ends by giving examples of these types of experimentations, called spike solutions.

Discussion

These three chapters were really informative and actually clarified several doubts I had from reading the previous chapters. The process of user stories makes a lot of sense and seems it could be extremely effective. I have never used this process and look forward to do so in the future. The book clearly explains pretty much every detail about it so I don’t think there are any faults in this work, at least from the perspective of someone that has never used XP programming.