XProgramming > XP Magazine > Unofficial XP FAQ
COLLECTED TOPICS: Adventures in C# | Documentation in XP | Book Reviews
Unofficial XP FAQ
Peter Gassman
09/01/1999
These questions came up in the MOVE project and have been answered by Kent Beck.
Contributed by the MOVE Team at FJA-Innosoft. Maintained by Peter Gassmann.
For info or questions, contact peter.gassmann@acm.org, and copy Editor, XProgramming.com.

When should the estimates for the stories be made ?

Before the commitment meeting. You might need some time to do some exploration, so you need to think about what should go into the next release before the committment meeting, and then do the necessary exploration / prototypes etc. do do the estimation.

Who should estimate the stories ?

The stories should be estimated collectively by the development team. All team members should have an understanding of the story.

When should the stories be split up in tasks ?

The splitting up takes usually place in the iteration planning meeting, right after the decision that the story would be part of the next iteration. Because additional questions will come up during the splitting, it will be useful to have the customers right there.

When should the tasks be estimated ?

The tasks should be estimated after the splitting, still in the iteration planning meeting. A task should be estimated by the person who takes the responsibility for the task.

Should the customer-visible estimates include the load factor / velocity already ?

Usually it is easier to have engineering-time estimates, and multiply them with the velocity only at the end to get the necessary calendar time. If the relationship to the customer requires it (for example if the customer can't understand a load factor of 3 or 4), it might make sense to include the load factor in the estimates. However, this will make reestimation more difficult, if just the load factor has changed.

Why should the stories be written on paper cards and not in HTML / Word etc. ?

It is much more intuitive to define priorities with different piles of paper than on a bullet-list on a sheet of paper or even on the computer-screen (and studies have shown that). Do the simplest thing that could possibly work !

What are the primary properties of a story ?

A story should be :

  • testable: you should be able to test the resulting code automatically with functional tests (written by the customer)
  • estimateable: you should have (or get) a feeling for the time needed to implement the story. As an example: if you need to do a tax system with a lot of details, you probably know from just this statement that the implementation time will not be days or weeks, but it will probably not be much more than 5 weeks. This is what you need: a rough feeling for the time needed. If you think that the story takes more time than that, you should try to break it into smaller pieces. Remember: if you find a implemention time above 5 weeks, this means "I don't know".
  • customer related (technical stuff like converting to new release of database etc. should not be a story)

How many stories do I need (eg. what is the granularity) ?

For a typical project of 6-12 months, 50-100 stories would be a good number. If you have too few stories, it gets difficult to define priorities (if you have only 3 stories, the user will never say "ok, we need the third story only in the next release"). If you have too many stories, the handling gets more difficult (the pile of paper gets to high, it will be impossible to order all stories on one table (unless you have a very big table)), to a degree where you won't use them anymore!

How big should a story be ?

A story should take 1-3 weeks to implement (in engineering time).

Are stories measured in calendar time or in engineering time ?

In engineering time. A typical story takes 1-3 weeks.

Are tasks measured in calendar time or in engineering time ?

In engineering time. A typical task takes 1-3 days. Be aware that you should integrate at least daily (no code should be left unintegrated for more than a day) ! This has the consequence that you will need to integrate for a 3-days task more than once.

Who should participate in the comittment meeting / iteration planning meeting ?

All members of the development team, plus the customers who may take the decision to include / postpone stories. Because all development team members will have decisions to make (which tasks to take responsibility for, estimates for these tasks), and because the immediate future of the project is discussed in these meetings, all development team members should be there.

What are the typical steps in code integration with CVS ?

  1. get the integration token (this is necessary to avoid that other people start integrating at the same time. You might use a special hat for that ("integration hat"))
  2. load the newest version from CVS (update), this should merge automatically with your local changes
  3. run all Unit-Tests, if they don't run at 100%, fix them
  4. commit all your changes
  5. return integration token

What are the most important metrics ?

  • delivered functionality versus planned functionality.
    This is basically the project velocity. Measure an iteration. If a developer has not had enough time, his load factor was too low, if a developer had not enough tasks, his load factor was too high. Combine the load factors of all developers to get the project velocity)
  • Bug reports from the users (a bug report by the users means that an error has slipped past the unit tests, so more unit tests might be required). You might want to try to relate this to the test coverage of the code (unit tests, functional tests).
  • 40 hours weeks (look at the time sheets of the developers)

Be careful with measuring system performance. Measuring it too early might lead to unnecessary performance optimization, which might lead to a complexer design / structure too early in the project

Do I need a single metaphor for the whole system or is it ok to have more than one metaphor ?

If you can find a single metaphor for the whole system, this is of course the best case. But it is also ok to have different metaphors for different parts of the system.

How long is a typical iteration ?

2-3 calendar weeks. This means that with a load factor of 2, 7.5 engineering days per developer can be planned in 3 calendar weeks.

What is a typical load factor ?

Load factors of 2 to 4 (you need for x engineering days (x * 2) calendar days) are quite common. You should measure your load factor / velocity constantly. You can measure it already during a prototype in the exploration phase.

How should I start planning an XP project ?

Try to find the stories. To begin with, just identify the story titles, then add details as necessary (the objective is that everybody knows what the story is about). Then try to answer the following questions :

  • How big ? (estimates of the stories)
  • What first ? (priorities, what goes into the first relase / iteration)

You will need to find the balance between necessary details for estimating the stories for the committment meeting (release planning) and the necessary details to implement a story (split it up in tasks etc.). You should not have to find all details for all stories before the first committment meeting ! Be aware that additional stories will come up during development, for example new stories, or stories which need to be split up.

To find the stories where you need to do some exploration (maybe a prototype or further investigation) to be able to estimate the story, sort all your stories by risk (by the risk that your estimation will be far off) into three piles. Then look first at the stories in the highest-risk-pile and explore these stories further, until you feel you can estimate the story close enough.

One indicator that you don't know enough about a story (what should be done, how it should be done) is when your estimate for the story is higher than 6-7 weeks. If that is the case, try to split the story, explore the story, write a little prototype. If the estimate for a story is too high, there is more risk in it (that you will recognize only late that you've underestimated the problem etc). Reduce this risk as far as possible.

How does the life-cycle of a story look like ?

see this image

Do I need to know how much time my team spends on writing tests, refactoring, doing simple design ? This would tell me that everybody is into "XP", right ?

All the components of XP are tightly related to each other. The beauty of XP is that you have all the "traditional" concepts of software development like design, analysis, integration and testing; but you switch between them at a very high rate (typically you have all activities during one hour of development). It is like riding a bike. You would not try to keep record of how much time you spend leaning to the right and how much time steering. It is the arrival at your goal without falling which is important.

I have difficulties to write tests if it is not business logic. How would I write a test for a JTree ?

Often, it is helpful to find two dimensions of a problem. For example, it will be difficult to check each HTML file you produce on-the-fly. But let's say you have a list of tags to fill up. If you can make sure that

  • you can find all the tags
  • and you can fill up a tag

you can be pretty sure that you will be able to handle any combination of the two without having to test each single combination
(do you remember vector calculus ?). Similarly, you will not be able to test the JTree as a whole. But you can test whether you
can insert an object as a child to an other object of your JTree. This gives you enough confidence that the tree will work.

What do you mean by "travel light" ?

A lot of things. Basically, it means that whenever a simple solution is enough for you, you should stick with it. Examples:

  • index cards are perfect for stories. You do not need any more. A electronic tool would probably save you some five minutes every other week, and it has a lot of disadvantages, too.
  • software specification in functional tests: you need the functional tests in any case. Therefore you don't have to carry an additional document along, since the functional test contains as precise a specification as there can be.

During pair programming, I feel like slowed down !

This will happen until the whole team is up to speed. It is like walking with one leg tied to your colleagues leg. But this is the
speed of the team as a whole ! Usually, it takes about 2 months to bring the whole team up to speed with pair programming. But then, pair programming will be more efficient than programming alone (in terms of the resulting quality and amount of production ready code).


During pair programming, I feel like disturbing my colleagues

Yeah. A "good" XP project is surrounded by a constant buzz (like a cloud above the team). People are communicating. Quite teams are a bad sign. Headphones in particular. You will have to make some re-arrangements of your office which makes you feel comfortable.



last change : 25.08.1999, 14:12, Peter Gassmann

XProgramming > XP Magazine > Unofficial XP FAQ
COLLECTED TOPICS: Adventures in C# | Documentation in XP | Book Reviews