This post describes how I use requirement points (or story points as they are called in eXtreme Programming) to manage the time aspect of software projects.
My use of requirement points are very similar, if not identical, to the way they are used in eXtreme Programming. The reason why I have decided to write about requirement points aside from eXtreme Programming is because I find them useful no matter what process/methodology/framework is used for developing software.
To enhance the explanation of requirement points I will use a recent project I worked on as a case study. However, I’ll start by defining the theory and then apply it to the case study in a later post.
Theory
What is a requirement point?
A requirement point is an arbitrary number that signifies a certain amount of work needed to satisfy a requirement.
The Process
Below is a simplified process outlining the phases where the requirement points come to play
1.0 Initial Estimation
Step 1.1) Baseline
We need to baseline the requirement point to some initial value. There are a number of techniques for doing this. Here are a few techniques that I find useful:
- Time-based
Assume that a single point is equivalent to given time span, e.g. 1 hour, 1 day, 1 week, or 1 month. - Scope-based
Assume that a single point is equivalent to a certain amount of work, e.g. 1 point equal to a basic C/R/U/D implementation for an entity).
The technique used depends on your personal preference. Many professionals refrain from using the time-based technique as its meaning keeps changing throughout the project as you will see later. However if you work with a customer that requires immediate time estimates the time-based technique can provide you with an initial estimate.
Step 1.2) Estimate Requirements
Using requirement points estimate all known requirements.
A rule of thumb in project management is to always breakdown work into smaller chunks that are easier to estimate. Each requirement may therefore have to be broken down into smaller tasks.
Step 1.3) Determine initial project velocity
The project velocity is the number of requirement points that can be implemented in one customer iteration. If you use the time-based technique to baseline the requirements point then the initial project velocity could be the number of hours or days that make up the duration of a customer iteration. The duration of a customer iteration is often recommended to be no longer than three weeks.
Step 1.4) Determine the velocity of each project member
Determine how many requirements points each project member is expected to complete each customer iteration. To avoid causing problems among the project members you may want to start all project members at the same level.
2. Iteration Planning
Step 2.1) Determine project velocity
Once again the project velocity is determined, but this time the focus is on the duration of the current iteration. If some members are not available full time, or public holidays are coming up, this will reduce the project velocity. You can reduce the project velocity using basic maths, e.g. if a project member is only available for half the iteration, you would remove half the velocity of the member.
Step 2.2) Requirements Selection
It is the customer or business representative’s responsibility to select estimated requirements worth the current project velocity. This will make up the iteration plan.
Step 2.3) Requirements Acceptance
I could also have called this step “Requirements Delegation”, but there is a theory that says that for project members to be truly effective they have to select their own work, so rather than implying that the project manager delegates the requirements selected from Step 2.1, it is instead implied that project members pick and accept the requirements they would like to implement. Project members pick requirements worth their personal velocity.
3. Implementation
Step 3.1) Tracking
While the project members are implementing the selected requirements they keep track of how many requirement points they complete. If a project member completes all the requirements he has accepted he will be able to pick more requirements from the pool of requirements (preferably the ones of high customer importance).
4. Evaluation
Step 4.1) Re-calculate project member velocity
The project member velocity is re-calculated by adding up all the requirement points he has managed to complete. In that way his personal velocity will go up if he has managed to complete more than he accepted, or down if he fell behind. This new velocity is important in that it will constitute the amount of requirements the project member is allowed to accept in the next iteration.
Step 4.2) Re-calculate project velocity
The velocity of all project members is summed up and determines how much progress was made in that iteration and how much effort is required to finish the remaining requirements. When the project velocity has been calculated the burn down chart is updated.
Note: The burn down chart is a graphical representation of the history of the project velocity. The chart can also be made for each individual project member.
Step 4.3) Customer Evaluation
The customer evaluates the system and decides if the development should go on or halt. If the customer decides to continue with the development the process jumps back to Iteration planning.
Conclusion
Using requirement points is simply and does not require you to follow eXtreme programming or any other specific methodology. It will require you to estimate requirements and keep track of how many points you complete, the benefits however are enormous as you will always be able to get a clear view of how much effort are remaining and how well you are performing. Furthermore it allows for auto-correction of project members with inaccurate estimation skills by providing them with a personal velocity based on their previous performance.
References
Fowler 2000, Planning Extreme Programming, 1st Edition, Addison Wesley
Beck 2005, Extreme Programming Explained, 2nd Edition, Addison Wesley
