Get certified - Transform your world of work today


Language for Discussing Releases

2 April 2007

Daniel LeFebvre
FreeStanding Agility

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

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.

Does Fit Indicates that even at the team’s slowest projected velocity, the target can be delivered prior to the deadline
Should Fit 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

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

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.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 0 (0 ratings)


Mike Cohn, CST,CSP,CSM,CSPO,REP, 4/11/2007 12:52:37 PM
There are some great ideas in here, Dan. Thanks for sharing them with us. You are very right that it is hard to give a project stakeholder a message like "We'll be late." We should probably all practice saying that 100 times in the mirror each morning until the fear of saying it goes away. And if we do tell someone "We'll be late" it sets up the wrong follow-on discussion. The discussion will probably be "Why?" or "Why, you jerk?" or "What can we do about it?"

The best response in a case like this would be "What do *we* do next?" and to answer that it is important that we have a very solid understanding of what will be in the release (under current assumptions), what won't be in and as you've diagrammed it what should be and what may not be. You've given us a great vocabulary for having release scope discussions with our stakeholders. Thanks.
Chris Lafosse, CSM, 9/23/2008 8:04:26 AM
I like the graphical presentation, and the use of "cone of uncertainty" / ranges. However, what I am always somewhat unclear of is how, using the projection method this represents, certain "real-world" factors are taken into account. That is - the future velocity is predicated on the team staying the same. All too often the team - especially over longer time scales which we're considering - will not remain the same. Team members will become unavailable, others will become available who may or may not have same skills, etc etc. How can we acknowledge these events in our predictions and illustrations?
Daniel LeFebvre, CEC,CSP,CSM, 9/30/2008 12:01:01 PM
One way to create the "cone" is to average the 3 highest and the 3 lowest velocities. Therefore, the cone is a empirical representation of the team's history. If the variability in team membership is part of the normal course of events, then the trend with cone represents it. If not, you may have identified an impediment (risk) that needs to be handled.
Anantha Narayanan, CSPO, 8/24/2011 11:02:30 AM
Great article. Also check Tyner Blain's post on the same topic which I found very informative.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up