Since grade school, we’ve been taught that being “late” is bad. Tardies and assignments turned in after the due date do, after all, “go on your permanent record.” With plan-driven project management and traditional status meetings, a similar stigma is attached to a project that is running behind. A late project is often met with pressure, questions of the team’s level of effort, or a reflection on your competence as a project manager. This lifelong association between late and bad leads to behaviors that can cause more harm than good when dealing with project work. These behaviors include popular games like:
- Status Chicken. Who will be the first to admit the project will not come in on time?
- Spin the Message. Find euphemisms like “things are a little tight” or “we ran into a little rough patch"
- Catch-up Fever. Convincing management and yourself that we can “make up the time” or that we need “just one breakthrough and progress will increase dramatically”
- Pressure Cooker. Turning up the heat by insisting the team work extra hours to get the project back in line.
The key to successful agile projects is to recognize issues early, shine a light on them, and resolve them. How do we recognize and communicate that a project is running behind without triggering feelings of guilt or fear that stem from either early life experiences or organizational cultural resistance? One way is to change the language for discussing releases. Instead of using harsh colors like “the project is red” or terms like “the release will be late,” switch to the more accurate statement that the required stories either “do not fit” or “may not fit” the desired timeline. This language is less threatening and can lead to early, productive discussions with the Product Owner or senior management on how to either reduce the content of the required product backlog or to find appropriate ways to increase the velocity to allow the needed features to fit the desired timeline.
To determine the “fitness” criterion in an objective way, we can use the cone of uncertainty, as described by Barry Boehm and Mike Cohn, and a burn chart. In Agile Estimating and Planning, Mike Cohn writes about using the cone of uncertainty to define a range of velocities for planning purposes. By plotting the planned, optimistic, and pessimistic velocities as projected trajectories, you get four regions on the burn graph.
Figure 1 shows a sample Burnup Chart with the cone of uncertainty, the target project effort, and the milestones or deadlines plotted.
Figure 1. Parts of a Burnup Chart
Figure 2 illustrates that by examining the intersections of a milestone with the target effort and comparing it with the regions defined by the cone of uncertainty, the state of the project can be determined.
||Indicates that even at the team’s slowest projected velocity, the target can be delivered prior to the deadline
||Indicates that the target can be delivered ahead of the deadline if the team keeps to its planned velocity
|May Not Fit
||Indicates that the team needs to exceed its planned velocity to deliver the target before the deadline
|Does Not Fit
||Indicates that even at the fastest projected velocity, the target cannot be delivered by the deadline
Figure 2. Fitness Regions
The project in Figure 2 is in good shape for its required functionality but will not be able to deliver all the desired features. This gives the Product Owner, the team and senior management confidence that this project will deliver on its commitments and will probably deliver added value beyond the required features.Another way to show this information is with a Release Summary Table as in Figure 3. The velocity column indicates how the velocity was derived and its range. The deadline column shows the date and the amount of effort that can be delivered by that date based on the velocities. The must effort column lists the amount of effort for all the required stories and the delivery dates based on the velocities. The story effort lists the same for the desired stories.
Figure 3. Release Summary Table
Early experiences have made it difficult for teams, project managers, ScrumMasters and team leads to recognize and communicate project delivery difficulties. With early projections and a language to allow constructive conversations with stakeholders, teams have a better chance of making the adjustments necessary to achieve project success.