The XP development cycle consists of two phases: ‘Release Planning’ and ‘Iteration Planning’. In release planning, we decide what should be delivered and in what priority. In iteration planning, we break the requirements into tasks and plan how to deliver those activities decided in release planning. The below figure ‘Actual essence‘ shows what actually these two phases deliver.
If you are still having the old SDLC in mind, the below figure ‘Mapping to traditional cycle’ shows how the two phases map to SDLC.
So let’s explore both these phases in a more detailed manner. Both phases “Release Planning” and “Iteration Planning” have three common phases: Exploration, Commitment, and Steering.
Release Planning
Release planning happens at the start of each project. In this phase, the project is broken into small releases. Every release is broken down into a collection of user stories. Now let’s try to understand the three phases in release planning.
Exploration: In this phase, requirement gathering is done by using the user story concept (please read the previous question on user story to understand the concept of user story). In this phase, we understand the requirement to get a higher level understanding. Please note, only higher level. The user story card is sized normally at 3 X 5 inch, so you can not really go in detail in that size of a card. We think it’s absolutely fine rather than writing huge documents; it sounds sensible to have to the point requirement paragraphs. So here is a step by step explanation of how the exploration phase moves:
- The first step is the user writes the story on the user card.
- Once the story is written, the developer analyzes it and determines if we can estimate the user story.
If the developer can not estimate, then it’s sent back to the user to revise and elaborate the user story. - Once the user story is clear and can be estimated, the ideal day or story (read about story point, ideal day, and estimation in the coming questions) are calculated.
- Now it is time to say to the user, OK we can not deliver everything at one go, so can you please prioritize? In this phase, the end user gives ranking to the user stories (in the next section, we will deal with how a user story is ranked).
- Once the user is done with story prioritization, it is time for velocity determination (in the coming section, we have a complete question on velocity determination).
- Agile is all about accepting end customer changes. In this phase, we give a chance to the end user to decide if they want to change anything. If they want to change, we request the user to update the story.
- If everything is OK, we go ahead for iteration planning.
The figure “Release planning” shows the above discussed steps in a pictorial format.
Iteration Planning
Iteration planning is all about going deep into every user story and breaking them into tasks. This phase can also be termed as detailing of every user story. Iteration planning is all about translating the user story into tasks. Below are the steps in detail for iteration planning:
- User stories which need to be delivered in this iteration are broken down into manageable tasks.
- Every task is then estimated. The result of the estimation is either ideal hours or task points (we will discuss about task points and ideal hours in the coming section).
- After the tasks are estimated, we need to assign the tasks to developers. Each programmer picks a task and owns responsibility to complete the task.
- Once a developer owns the responsibility, he should estimate the work and commit to completing it.
- In XP, on any development task, two developers should be working. In this phase, the developer makes the partner of his choice for developing a task.
- In this phase, we do the designing of the task. We should not make lengthy and comprehensive design plans; rather it should be small and concentrated on the task. In traditional SDLC, we have a fully devoted phase for designing and the output is a lengthy and complicated design document. One of the important characteristic of a software project is that as we come near execution, we are clearer. So it’s best to prepare the design just before execution.
- Now that you and your partner are familiar with the design plan, it is time to write a test plan. This is one of the huge differences when compared to the traditional SDLC. We first write the test plan and then start execution. Writing test plans before coding gives you a clear view of what is expected from the code.
- Once the test plan is completed, it is time to execute the code.
- In this phase, we run the test plan and see if all test plans pass.
- Nothing is perfect, it has to be made perfect. Once you are done with coding, review the code to see if there is any scope for refactoring (refactoring is explained in more depth in the coming sections).
- We then run the functional test to ensure everything is up to the mark.
One of the important points to realize is a project is broken down into a set of releases which are further analyzed using short user stories, the user stories are further broken into tasks, which are estimated and executed by the developer. Once a release is done, the next release is taken for delivery. For instance, the project shown in figure ‘Release, stories, and task’ has two releases.
