In the last post post of this series, we have discussed an Agile project management estimation technique, useful when planning in a context of high uncertainty.
The estimation of tasks' sizes using story points.
The estimation of tasks' sizes using story points.
The concept at the core of the evaluation by story points technique is to estimate activities’ related efforts, instead of activities’ actual durations. Then, as the project progresses, we will be able to transform points into time, using performances achieved in previously accomplished activities.
In this post, we will talk about why this kind of approach works. We will go a little more in-depth, giving evidence of some common pitfalls and solving doubts that typically emerge when approaching this technique.
Why it does work
Relative estimations are easier than absolute ones
It is much easier estimate something comparing it to what we already know, instead of making up a precise quantification out of the blue. You can get evidence of this claim at almost any moment in your life, in which you have to explain something to someone. What would you rather say “Hey Jack, do you know that Tom is 1.76 meters high and weights 97 Kilograms?” or “Hey Jack, do you know that Tom is almost as high as me, and weights more or less the same as Pete?”
Velocity is the great equalizer
The team could estimate its velocity as the average of the number of story points achieved in the last N iterations. It would be pretty useless for the team committing to the implementation of 25 story points in the next iteration if the average velocity achieved in the last 5 iterations is 10. The velocity concept and the averaging operation will smooth out the effect of any unforeseen problem (or luck) that the team may have encountered in performing the job.
The team could estimate its velocity as the average of the number of story points achieved in the last N iterations. It would be pretty useless for the team committing to the implementation of 25 story points in the next iteration if the average velocity achieved in the last 5 iterations is 10. The velocity concept and the averaging operation will smooth out the effect of any unforeseen problem (or luck) that the team may have encountered in performing the job.
Agile teams are, by definition, multidisciplinary teams
The presence of people with many competencies and skills in the team helps in achieving meaningful and reliable estimations. The number of points for one story should not be decided just by an individual. It should come from negotiations and confrontations between all the team members. This approach leads us to the next principle.
The presence of people with many competencies and skills in the team helps in achieving meaningful and reliable estimations. The number of points for one story should not be decided just by an individual. It should come from negotiations and confrontations between all the team members. This approach leads us to the next principle.
The team, not the individuals, commits to a velocity
The work to do, in an Agile team, should be shared by many team members. It is all right to have a specialist in software testing, as long as he/she won’t take care of all the testing. The most skilled team member would probably take care of the more delicate tasks in its specialization domain, but he/she have not to exclude other team members from this kind of activities. Just, in this case, the team can commit to a common objective. Otherwise, you won’t have an Agile team; you will end up with a bunch of professionals, trying to deliver something in their specialization domain without getting in the way of other people.
The work to do, in an Agile team, should be shared by many team members. It is all right to have a specialist in software testing, as long as he/she won’t take care of all the testing. The most skilled team member would probably take care of the more delicate tasks in its specialization domain, but he/she have not to exclude other team members from this kind of activities. Just, in this case, the team can commit to a common objective. Otherwise, you won’t have an Agile team; you will end up with a bunch of professionals, trying to deliver something in their specialization domain without getting in the way of other people.
To have it working
The team composition should be fixed
Team velocity is based on estimations of task’s size and execution performances. Usually, some iterations are necessary to reach convergence and give reliable evaluations.
As you may imagine, if the team’s composition is frequently changed, there is no way to reach a condition of stability.
Agile teams must be made up of T-people
Since in an Agile teams, estimations are made collectively, and tasks of the same kind are shared among different resources, you need the so-called T-people. That is to say, people who are extremely proficient in a given area of the project, but sufficiently skilled to be helpful in many others.
Since in an Agile teams, estimations are made collectively, and tasks of the same kind are shared among different resources, you need the so-called T-people. That is to say, people who are extremely proficient in a given area of the project, but sufficiently skilled to be helpful in many others.
You need ants, not tigers
Agile teams must be made up of average performers, who care more about the team than themselves. Do not directly jump to conclusions; you do not need dumb people. You need a well-balanced set of smart people, with comparable performances. Believe me, you do not want to have lone rangers or superstars in an Agile team.
Agile teams must be made up of average performers, who care more about the team than themselves. Do not directly jump to conclusions; you do not need dumb people. You need a well-balanced set of smart people, with comparable performances. Believe me, you do not want to have lone rangers or superstars in an Agile team.
You have to make a transition from the standard project management paradigm
Obviously, if the team has to commit on an objective to be reached in an iteration, all the members should have a certain degree of freedom in selecting the target itself. This approach requires a particular shift in the project management paradigm.
Obviously, if the team has to commit on an objective to be reached in an iteration, all the members should have a certain degree of freedom in selecting the target itself. This approach requires a particular shift in the project management paradigm.
In an Agile team, the project manager must delegate more than in a standard environment. The team must be free to select the tasks to perform in the iteration, balancing the stakeholders’ requirements with the team’s capabilities.
Common pitfalls
Story points define the size of an activity related to the other ones; do not try to convert them to man/hours and to redefine activities’ durations. Story points conversion is a dangerous road to walk by. Work with story points and use velocity.
Do not change estimation of past stories
Sometimes you may be tempted to change the points size of some features; maybe because you become aware that a task is much more difficult (or easy) to perform than previously expected. In such a case resist the urge to change the task’s size. Remember, velocity is the great equalizer. The story points and velocity system will take care of such eventualities. If the task to perform is much more complicated (or simple) than expected, you will experience a physiological velocity increase (or decrease) in next iterations.
Sometimes you may be tempted to change the points size of some features; maybe because you become aware that a task is much more difficult (or easy) to perform than previously expected. In such a case resist the urge to change the task’s size. Remember, velocity is the great equalizer. The story points and velocity system will take care of such eventualities. If the task to perform is much more complicated (or simple) than expected, you will experience a physiological velocity increase (or decrease) in next iterations.
Different teams’ velocities are meant to be different
Once I hear a project manager saying “Team A is performing better than team B; in fact, team A achieved a velocity 5 points greater than the one obtained by team B.” Dead wrong. Different teams, with different tasks and different estimations probably will have different velocities, but this means nothing. Remember that story points have just a comparative meaning and are subjective from team to team. Do not compare teams’ performances basing on their velocities.
Once I hear a project manager saying “Team A is performing better than team B; in fact, team A achieved a velocity 5 points greater than the one obtained by team B.” Dead wrong. Different teams, with different tasks and different estimations probably will have different velocities, but this means nothing. Remember that story points have just a comparative meaning and are subjective from team to team. Do not compare teams’ performances basing on their velocities.
A last comment
If you think that an agile planning approach is not a silver bullet, you are perfectly right.
Agile planning is an extremely useful tool, that should be present in every project manager’s tool bag; nonetheless, you have to select carefully, which projects could benefit from it.
Furthermore, do not forget that also the business environment in which the project lives should be ready to adopt such an approach.
Quest' opera รจ distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.
