Extreme Programming Practice
The Planning Game
Every 2 weeks:
- Developers estimate the development time of candidate features
- The client selects 2 weeks of features, based on business value.
To plan a project, we need to know enough about a requirement to estimate the time needed to implement it.
- We need to have a sense of the details. We do not need to know actual details.
Requirement details change as the client sees the project develop.
- Those changes are good, according to agile principles.
- Trying to capture requirement details early therefore wastes time.
A user story is a summary of a conversation between the client and the developers that captures a requirement's essence.
- Developers estimate an amount of time to implement the requirement, based on the conversation.
- The client prioritizes requirements, based on their value.
- User stories summarize ongoing conversations: specifics change and are elaborated over time.
(We will use something slightly more formal than a user story and less formal than a use case.)
Splitting and spiking
- A user story that is big tends to be underestimated. Split it into a set of smaller stories to get better estimates.
- If you don't know enough to estimate a small story, spike it:
- Prototype the simplest possible version of it.
- E.g., if you have not used JDBC, get a simple database working.
Task Planning
- A task can be implemented in a few hours.
- Developers sign up for tasks.
- Each developer has a task budget based on how many tasks they completed in previous cycles.
- Each developer must stay within his/her budget.
- The initial budget is simply a guess.
- How do we reconcile pairing 2 developers with wildly different task rates?