Initial Exploration


At the start of the project, the developers and customers have conversations about the new system in order to identify all the significant features that they can. However, they don't try to identify all features. As the project proceeds, the customers will continue to discover more features. The flow of features will not shut off until the project is over.

As a feature is identified, it is broken down into one or more user stories, which are written onto index cards or their equivalent. Not much is written on the card except the name of the story (e.g., Login, Add User, Delete User, or Change Password). We aren't trying to capture details at this stage. We simply want something to remind us of the conversations we've been having about the features.

The developers work together to estimate the stories. The estimates are relative, not absolute. We write a number of "points" on a story card to represent the relative cost of the story. We may not be sure just how much time a story point represents, but we do know that a story with 8 points will take twice as long as a story with 4 points.

Spiking, Splitting, and Velocity

Stories that are too large or too small are difficult to estimate. Developers tend to underestimate large stories and overestimate small ones. Any story that is too big should be split into pieces that aren't too big. Any story that is too small should be merged with other small stories.

For example, consider the story "Users can securely transfer money into, out of, and between their accounts." This is a big story. Estimating will be difficult, and probably inaccurate. However, we can split it into many stories that are much easier to estimate:

  • Users can log in.

  • Users can log out.

  • Users can deposit money into their accounts.

  • Users can withdraw money from their accounts.

  • Users can transfer money from one of their accounts to another account.

When a story is split or merged, it should be reestimated. It is not wise to simply add or subtract the estimate. The whole reason to split or merge a story is to get it to a size at which estimation is accurate. It is not surprising to find that a story estimated at 25 points breaks up into stories that add up to 30! Thirty is the more accurate estimate.

Every week, we complete a certain number of stories. The sum of the estimates of the completed stories is a metric known as velocity. If we completed 42 points' worth of stories during the previous week, our velocity is 42.

After 3 or 4 weeks, we'll have a good idea of our average velocity. We can use this to predict how much work we'll get done in subsequent weeks. Tracking velocity is one of the most important management tools in an XP project.

At the start of a project, the developers will not have a very good idea of their velocity. They must create an initial guess by whatever means they feel will give the best results. The need for accuracy at this point is not particularly grave, so they don't need to spend an inordinate amount of time on it. Indeed, as good old-fashioned SWAG[7] is usually good enough.

[7] Scientific Wild-Assed Guess




Agile Principles, Patterns, and Practices in C#
Agile Principles, Patterns, and Practices in C#
ISBN: 0131857258
EAN: 2147483647
Year: 2006
Pages: 272

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net