At the start of the iteration, a team commits to a goal and a certain amount of work. Burndown charts help a team to monitor their own progress against that goal. The team works together in a room with a process facilitator and product owner. Everthing seems to be okay, and yet, the team doesn’t fulfill its commitment. What to do?
How Bad is This?
If the team is just adopting Agile Work methods, is a new team, and is on a new project, then this problem is common and to be expected as an early part of the team’s learning. In other circumstances, this is a disfunction.
The severity varies greatly, but the worst thing that can happen is that the team gets in the habit of doing this regularly and therefore starts to believe that it is okay. It is not okay. One of the most important aspects of Agile Work is the closure of work completed at the end of the iteration.
This closure has all sorts of benefits: a feeling of accomplishment for the team, delivery of real value to the customer on a regular basis, better capacity planning based on actually completed work history, and accurate feedback from the customer on a regular basis. If the work is not completed, none of these benefits are possible.
One way the team fails to get to done is simply through poor estimation and planning. There are several key practices to use in agile planning: tracking velocity, tracking availability, estimating work and iteration planning. In order to correct this type of failure, try the following simple iteration planning steps:
1. At the beginning of an iteration, the team records it’s “velocity” for the previous iteration. This number is equal to the beginning estimated size of work for the iteration plus the original estimated size of any work added during the iteration minus any work left over. The team may also wish to record exactly how many person-days were worked in the previous iteration based on when people were sick, on vacation, in training, left the team or joined the team. (If it is your first iteration, you may want to use drag factors – the subject of a future article – or the team may just take a wild guess as to its velocity.)
2. The team then collaborates to put an estimate on each piece of work to be done. There are several systems for doing estimates including “Story Points”, “Ideal Hours/Days”, or “Ping-pong Balls”. Sum these estimates up into a total proposed work size for the iteration. If the team determined person-days worked in the previous iteration, then estimate person-days available in this iteration taking into account the same factors.
3. If the estimated work to be done is greater than the team’s velocity for the previous iteration (and optionally factoring in the ratio of person-days worked/available) then remove the lowest priority scope from the iteration until the estimated work to be done fits the team’s capacity.
Obstacle Removal Failure
Sometimes a team will be unable to complete the work of the iteration due to an obstacle that was not cleared. Possibly the obstacle was not identified or only identified very late in the iteration. Possibly the Process Facilitator was irresponsible or incapable of removing the obstacle for the team. Or possibly the organization around the team was unable to remove the obstacle or forbade its removal.
The team must be certain of the nature of the obstacle. A brief pull-up or more in-depth retrospective may be necessary and thinking tools such as the “Five Whys” may be useful. Once the obstacle and its nature are understood, its consequences must be fully exposed to all members of the team and all stakeholders. In the full light of the obstacle’s nature and consequences, the team and stakeholders can decide what to do: remove the obstacle, mitigate its effects, or live with it. Choosing to live with an obstacle should be seen as a last resort and even in this case resolving the obstacle should be put on the work item list to be revisited sometime down the road.
Regardless of the status of the obstacle, the team must adjust its planning for the remainder of the iteration or the next iteration in order to take into account how it was dealt with.
Failure to Abort the Iteration
Sometimes information comes to light that invalidates the work of the team for the iteration. The Process Facilitator, the team and the Product Owner must collaborate to decide if the iteration should be aborted early. If this new information is ignored for any reason, then a team may continue working on the iteration but not get to done.
Aborting an iteration is a healthy thing to do and is a legitimate part of being agile. It should not be considered a failure. Aborting the iteration can be a powerful means of communication and re-planning. It is meant to be done rarely and it is designed to send a strong message.