Xp At Project Startup

MarkSmall? wrote:

I have to write a paper on how XP fits with ProjectManagement techniques. Having little knowledge of XP I am looking for more experienced views on XP in areas such as:

 1. Controlled & organised start to the Project
 2. Involved  customers with improved customer communication
 3. Effective reviews of progress against a plan
 4. Effective communication channels with all stakeholders i.e. customer, development team, management team etc.
 5. Effective & appropriate decision & control points
 6. Managing Complexity

XP starts at the point that a project is authorized. At that point stakeholders, developers, business analysts, and QA folks meet for a few days to a week to discuss business needs and requirements. This is called "exploration". Not much is written down during this period, even though detailed requirements are discussed. It's not written down because at this point details are likely to change. What *is* written down are the names of features. They are written on cards, and called "stories". They are not actually narratives stories as some of the literature would have you believe. They are just the names of features like "Login", "Logout", "Deposit", "Withdraw", etc.

Having assembled a partial deck of stories, they are estimated by the developers. These estimates use arbitrary points that are relative to each other, but have no absolute meaning. A complex card might be given an estimate of 10. A simple card might be given an estimate of 2. The only rule is that a card with a 4 should be half as hard as a card with an 8. Cards larger than 10 are usually broken down into smaller stories.

This process of identifying features and estimating them never ends, It continues throughout the life of the project. The deck is continually getting new cards added, and old cards deleted or changed.

Finally, the developers make an educated guess at the number of points they can do in a week. This guess is crude and there is no need for accuracy. The stakeholders pick cards from the deck that add up to this number. So if the developers think they can get 80 points done in a week, the stakeholders pick cards that add up to 80.

The picking of cards is interesting. Stakeholders pick the cards with the best ROI. They look at each card and compare it's business value to its cost in points. The 80 points they pick are the 80 points that carry the largest ROI possible from the deck.

The developers then implement the deck of 80 during the week. On wednesday at noon those cards that total up to 80 (known as the iteration plan) should be split into two decks: those that are done, and those that aren't. The sum of points in the done deck should be 40. (To do this process you must be able to divide by two). Let's say that there are only 22 points in the "done" deck. Then it's likely that by Friday the team will get no more than 44 points done. SO the stakeholders pull out 36 points from the "undone" deck.

Let's say, by some miracle, the team finishes all 44 points on Friday. Now we know the team can do about 44 points per week. So on Monday the stakeholders pick another 44 points (which may, or may not include some of the 36 that were removed from the previous iteration). Now let's say that by Wednesday the team has 31 points in the "Done" pile. They might get 62 points done this week. So the stakeholders pull out another 17 points and put them in the "undone" pile. By friday the team has 58 points done. The remaining 3 points go back in the pile, and now we know that the team can get 58 points done in a week. On monday the stakeholders pull out another 58 points. And so it goes.

What does "Done" mean? A card is not done until it passes its acceptance tests. These acceptance tests are written by the stakeholders at the beginning of each iteration. On monday, the stakeholders (business analysts and QA) select the cards for the iteration, and then they write the acceptance tests for those cards. These acceptance tests should be done by Wednesday. If they aren't then some programmers hop the line and help finish writing them.

The acceptance tests must pass before a story can be said to be done. Indeed, the acceptance tests are the only criteria for "done-ness". Thus, the acceptance tests become the detailed requirements document.

The acceptance tests are also automated. They are written in a high level requirements language (see www.fitnesse.org) so that the developers or stakeholders can push a button and see the tests pass or fail. A story is not "done" until it passes it's automated acceptance tests.

Developers write code by writing tests first: See http://www.butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd.

All of these practices, and many more, need to be managed. Data must be collected, collated onto charts and reports, and presented to management. That is the role of the project manager.

Project managers are just as necessary in XP as they are in any other discipline. Their role is roughly the same. However, the data that they collect and the schedule they collect it on, is very different.

-- UncleBob (reposted from the XP newsgroup)