XP Installed Chapters 4-6

XP Installed, Ron Jeffries; Ann Anderson; Chet Hendrickson

Todays XP Installed reading covers the topics of User Stories, Acceptance Tests, and Story Estimation. Let's get started.

Chapter 4 is on User Stories. A user story is a short description of the behavior of the system from a users perspective. There are two core ideals to a story: keep it small/simple/short, and don't let the programmers write them. Keeping a story small allows it be easily adapted to a clients changing expectation of a system, and has the added benefit of localizing functionality to a few cards. Keepings the programmers out ensures client interaction, and ensures that requirements and understanding originate from the customer. Now, just because the programmers don't write them doesn't mean they're not there during the writing- programmers are responsible for (usefully) getting the client to expand on an idea- basically helping to make the clients vision clearer in their own minds. Probably the most important concept from this chapter is that a user story is a promise for a conversation, not necessarily a specification.

Chapter 5 is on Acceptance Tests. The ideal is that acceptance tests are initially customer provided tests for what constitutes a system that can be deployed to users. The tests can be expanded upon by programmers to meet a sort of overall organizational acceptance test, but the core ideal is "Is it ready for release?". The ideal in Acceptance Testing is automated tests. Automated tests mean that limited to no programmer interaction is needed to run through an entire test suite, verifying nothing new has been broken, and verifying that the test has been met. Ideally acceptance tests come along directly with the stories, such that a story has a well defined 'implemented' boundary.

Chapter 6 is on story estimation. The key idea from this is to assign 'points' to stories, and then figure out and adjust your actual velocity. Another concept is that of relative estimates- taking completed work, guessing the relative difficulty of similar work, and using that to derive an estimate. If you're starting out on a new problem, something you can't relate to or reliably estimate on, you can start on a spike- a short quick step in development to get a feel for the complexity and issues involved. And that covers the important parts of estimating.

Discussion:

1. Why is this paper interesting or significant?

It gives instructions and advice on estimating projects, determining when a project is finished, and delves into a core client <-> programmer communication strategy.

2. What are the faults of this work?

I've always felt that trying to estimate things in terms of points was destined to miserable failure. No one outside of the development team has any idea what a point means, and even if they did have "1 point ~= 1 week", the first question would be "why didn't you just say it'll take 3 weeks?". There's a valid reason for using points instead of hard time- hard time encourages a programmer to estimate in terms of time, which they traditionally underestimate; where as points encourage relative estimation, which may be more accurate. If poorly implemented (programmers keep track of what a point means; which, we're programmers, tracking pointless points is what we do), this benefit goes away, as the programmer maps between mental models "Okay, I think this'll take about 4 days, last iteration we were at pi points per fort night, so this should be 1/e points", which is counter productive.


I also disagree with their handling of acceptance testing. The primary end acceptance test is putting a product in front of the client and seeing what they think. This process can't really be automated, and a fair number of what they will mention will be small items, which may not be worth the test burden. But, that's just my perspective.

3. What is the possible future work extending from this work?
Half decent estimates with a method for communicating system goals between client and programmer. I'm not sure how large an issue this will be with the touch wrist band device, as I'm unsure if we have a customer, and I'm unsure if we specific attainable goals, or if its more of a "Get what you can done" project.