Protect Your Agile Team from Status Report Pressure

 

In agile, you as scrum master, must protect your team from outside distractions and pressure. One source of pressure is the leaders' desire for status updates. It is a source of pressure because agile values and priorities focus on getting the work done, not on trying to estimate how long until completed. So, it is not surprising that two comments to my article Winning the Organizational Transition to Agile requested more ideas for communicating to sponsors and stakeholders when your agile effort will be "done". So Deepak, Stephane, and others with this same question, this is for you.

Agile embraces the fact that requirements are basically impossible to document fully and completely before the design and development get started, and addresses this by continually showing the customer (for example, business representatives) results, asking for feedback and responding appropriately with new development. Teams respond to comments like this:

• "Oh, looks like we forgot some steps."
• "We thought we wanted that design, but it is not going to work."
• "We see some opportunities here looking at your latest demonstration and want to update requirements."

Even with drastic changes in scope, the development team remains in control until the product owner and customer representatives are satisfied with the result. While this method is better for the development team, it makes determining "the end" very difficult.

But therein lies the solution! If it is your customer who tells you when your work is done, it makes sense to leverage that relationship when you define status. With this in mind, follow the steps below to build a status statement.

Target End Date.  Assume that organizational leaders want a status summary that will tell them an end date plus any risks/issues/impediments that could interfere with the end date. The first part of the status summary must have an end date, but for agile, a more accurate term is Target End Date. Certainly, at the beginning of the effort, despite having few risks and zero impediments, there are many unknowns, it needs to be communicated as just a target. This can be estimated using a number of user stories, even total story points, distributed into a given number of sprints.

You should run your estimate by your product owner and/or sponsor for confirmation, adjustments and approval.

This is a very rough estimate, so now it is important to communicate just how rough to set expectations of the leaders. It is important to communicate that, even though there is low risk and no issues/impediments, the team is not naturally "Green" and on track to that date, because you just don't know in agile. And this is important as well: If you do not meet the date, it should be clear that no one necessarily is doing anything wrong. Change is a natural part of the process.

Confidence Level.  One way to communicate the roughness of your estimate is by communicating your confidence level in that target end date.

• Keep it simple by using "Low/High".
• Three options, "Low/Medium/High", can be used if you can keep from overusing "Medium" thereby making it meaningless.
• Some leaders prefer (Read that: "Require") more precision. Try a percent, such as 25% or 75% confidence level.

Generally, early on in the project, you'll have a low confidence level. Later as you get toward the end and most user stories have been completed, you have a higher level of confidence that the end date provided is accurate. A major impediment may lower confidence level.

Again, you do not have to be anxious over the Confidence Level measure. Collaborate with the product owner and even some subject matter experts. There should be agreement all around here so that when a leader probes further, the rationale is solid, customer/business-based, and everyone has the same story. A real benefit here is that confidence level can be based upon the subject matter experts' and product owner's understanding of what they do not know in order to complete the scope of the effort.

Putting all this together, the summary statement on a status report can look something like these examples:

Example 1:  Target end date for beginning of project with many sprints pending.

Target Deployment Date: 25 July, 20XX    Confidence level: Low (Unknowns in early development).

Example 2:  Same project later with just a few sprints estimated as remaining.

Target Deployment Date: 25 August, 20XX    Confidence level: High (No impediments, near completion of development).

Example 3:  Project near the end but with an impediment.

Target Deployment Date: 15 February, 20XX    Confidence level: Low (Despite nearness of target end date, impediment discovered requiring research to determine next steps.)

In the above example, additional status bullets can be provided to describe that limited progress can be made until impediment is resolved, re-design may be necessary or that partner resources may not be immediately available to assist in research.

This agile-friendly format is not expected to solve everyone's problems. You may think, "Well my leaders are not going to agree with this format". OK, maybe you can find a similar format that will work. If nothing works, you do not have a leader communication problem. You have an organizational change problem, which requires you to escalate along a much different path. This was the point of the original article, and you are now stuck in a two-article reading loop.