Before you start Extreme Programming
There are certainly people who hold this attitude, and who believe that they are doing XP – that's the nature of a misconception! The XP Customer Bill of Rights, which was presented in an earlier column, is very clear on this point:
The customer has the right to plan on a large scale with costs and options.
Jumping into coding without understanding at least something of the requirements would deny the customer this right.
Just like an other software development project, we shouldn't start an XP project until we've performed some return on investment (ROI) analysis. To do this, we need to be able to estimate both the costs and benefits of the project, which requires at least some understanding of the requirements. The benefits estimation is up to the customer, and XP is relatively silent on this – the most common approach to benefits estimation is to do whatever you were doing before you starting using XP.
The cost estimation needs to be done by the programmer team. An XP programming team expects to get requirements as a list of stories, where each story has just enough detail for the programmers to be able to estimate it. This is a subjective measure – depending on the team's experience with the technology and in the problem domain, some stories will require very little detail, and others will require a great deal.
Discuss this in the Builder Forums
Do you have a related question or comment? You can access our forums from here and post your questions, reply to other users, search for answers and more.
The underlying principle here is that although we need enough detail to estimate the overall cost of the project, any extra detail is potentially counterproductive. This isn't a new idea, and it isn't unique to Extreme Programming. In ""=""> (1996), Steve McConnell argues that one important contributor to managing scope is to begin with what he refers to as a 'minimal specification'. McConnell identifies the following problems with traditional specifications:
The process of producing estimates might require exploring and quantifying the critical success factors, creating vision statements, exploring alternative designs, producing user interface prototypes, storyboarding, or any other technique that can help clarify the project. The XP qualifier would be not to exclude any of these techniques, but only to use them when they help the team quantify either the costs or the benefits, to the level required to establish feasibility. Even this simple description should make it clear that there is plenty of work to do before an XP project team is ready to begin implementation.
Once we've decided that the project is feasible, we move on to the next step in the XP planning process, which is to break the project up into a series of releases. Releases are often keyed to particular dates (contract dates, trade shows, quarterly releases etc.), and frequently have a theme ("The Accounts Payable release", or "Flexible Payments"). Releases help the customer focus on splitting stories into high value (for early releases) and low value (later releases). They also act as additional constraints on development – without constraints, there's no incentive to make compromises or trade-offs, but if everyone knows the "Flexible Payments" release needs to be completed on July 6, there's a lot more focus and consideration.
The release plan isn't something set in concrete – it's a plan, not a prediction. It will change as the business gets feedback by using interim deliverables, and as changes in the marketplace are reflected in changed business priorities. It will also change if the programming team realises that some groups of stories have been systematically over or under estimated. It reflects our best understanding of functionality, priorities and dates at a given moment in time.
Within a given release, work is scheduled in iterations. Releases are usually on the scale of months, while iterations are on the scale of weeks (my personal preference is for iterations of one week). Short iterations often force the customer to break stories down yet again, and in doing so distinguish between high value and low value parts of the same story. Within an iteration, stories can be broken down into technical tasks, which are the responsibility of individual programmers, and can be scheduled within the iteration taking into account technical dependencies, if this is required.
So a productive XP project has planning on at least three levels – initial planning, release planning and iteration planning – and many XP projects have a fourth level of technical task planning as well. Quite a far cry from the idea of "jumping into coding".
Steve Hayes is the Software Development Manager at Internet Business Systems (IBS). IBS provides agile methods consulting and development services, and browser hosted solutions to the financial services industry.