For many organizations, status reporting is an en masse activity, generally allocated to time-based increments where employees stop what they are doing in order to provide management with a ‘snapshot’ of their work progress (e.g. monthly status updates). This monthly reporting cycle is intended to provide frequent enough updates to keep management aware of the status of the work in their area – without overloading the team with reporting activities (or the manager with paperwork to review). It creates a paper productivity trail where managers can confidently take action based on the appearance of productivity provided in these reports – and employees can continue focusing on their ‘real work’ for the next 30 days.
In the Agile world, status reporting is an ongoing activity. The same environment that enables delivery teams to be self-managed also creates an obligation for the delivery team members to keep others in the organization aware of the status of the work that they are doing. This obligation is not just for their managers, it is equally important to keep the business owners aware of the delivery team’s progress – and, more than anything, it is a tool for the delivery team to manage itself.
The Agile world has found that the best way to incorporate status reporting in delivery team work is to allow teams to use the same tools to manage and track their own day-to-day work as their managers use to oversee their progress. This means that reporting does not need to be an added step in the delivery team’s work; tracking the progress of their activities is an inherent part of their daily routine.
It is important to emphasize that progress reporting on Agile activities is not the daily tracking of hours in a timesheet. Agile approaches are far less focused on what time has elapsed, and far more focused on what actual business value has been produced. That is why the Agile world uses tools that track the progress of work completed and effort remaining to achieve the agreed objectives.
The four tools that are most commonly used in Agile approaches are:
1. requirements backlogs
2. delivery backlogs
3. burndown charts
4. executive dashboards
The requirements backlog
The requirements backlog43 (described in Chapter 5: Responsive Planning) is a tool where business owners can record and prioritize their business requirements for each iteration – and where delivery teams can record the progress of their work during each iteration against these requirements.
The delivery backlog44 is a tool used by the delivery team to track the details of their day-to-day work for each iteration, including breaking down each business requirement/activity into specific tasks that the delivery team members need to complete for that requirement to be met. For example, if one of the activities in the requirements backlog for planning a corporate event is ‘reserve a venue,’ the corresponding task entries in the delivery backlog may be:
- Visit potential venues.
- Select the preferred venue.
- Negotiate the contract for using the selected venue.
The executive dashboard
Executive dashboards are used to summarize the progress within (and across) Agile teams against their stated objectives. These tools provide management with an ‘at-a-glance’ view of the key metrics that the organization requires to monitor productivity levels (and business-value generation) across the organization.
Burndown charts are visual tools within the requirements backlog, the delivery backlog and the executive dashboard that enable Agile teams to track their rate of productivity (their velocity) for the current iteration, to self-manage their productivity levels based on this information, and to use it as input in estimating the amount of work that they can reasonably achieve in future iterations.
Each of these tools is described in further detail later in this chapter.
Backlogs, burndown charts and executive dashboards are valuable tools for monitoring the progress of the work that is undertaken by the delivery teams, particularly for day-to-day status tracking. Most important, however, is the progress reporting that is done as part of the outcomes review session at the end of each iteration.
Where a monthly paper report describes completed (and pending) work using text, bar charts and graphs, the outcomes review session at the end of each iteration provides the business owners with hands-on outputs in an interactive discussion forum. Unlike the graphs and charts in a monthly report that can be handcrafted to portray work in the best possible light, outcomes review sessions put this work under the microscope, leaving little opportunity for the delivery team to embellish their accomplishments.
With the outcomes review sessions, issues that are impacting organizational productivity are no longer resigned to be red text on page three of a paper report; they are addressed (and ideally resolved) hands on with key decision makers. This makes the outcomes review session a much more valuable and meaningful source of progress information for the organization than any two-dimensional report (including the Agile tracking tools) can provide. The delivery team is positioned to get direct feedback on their work from the business owners – and the organization is positioned to get ongoing value from the delivery team from the minute that the outcomes review session is completed.
It is interesting to note that the timing of four-week iterations aligns closely with the timing of monthly reports. This means that Agile teams are also able to use outcomes review sessions to report on their progress in conjunction with the standard reporting cycles for the organization overall (if required). The information that is recorded in the requirements and delivery backlogs can even be used to feed data into these corporate reports to minimize the overhead of monthly report generation for the delivery team.
If productivity is the measurement of how much business value the delivery team brings to the organization, then status reporting of Agile work needs to be able to track how much business value the delivery team has produced in each iteration – and when additional business value is anticipated to be delivered.
As described in Chapter 6: Business-value-driven Work, Agile approaches initially use expected business-value measurements as part of the iteration planning sessions in order to determine:
- The work that should be undertaken by the delivery team.
- The order in which work should be completed (i.e. the top-down priority order in the requirements backlog).
The expected business-value calculation formula in that chapter identified that one of the ways to assess the value of an actionable goal was to determine the percentage of work that the goal represents within the value of an overall initiative. Conversely, the progress (and the corresponding business value) of the overall initiative can be determined by measuring the progress of each of the actionable goals within that initiative.
For example, if the business value of a new product that the organization is launching is projected to be $3.2 million – and the website for that product is expected to generate 75% of that revenue ($2.4 million) – then the work required to deliver that website can be tracked as a percentage of the overall business value of each requirement being delivered:
- Build the website structure = 40% of the business value ($960,000).
- Create an e-commerce capability to process orders = 30% of the business value ($720,000).
- Provide an interactive service that allows website users to customize the product to their requirements = 20% of the business value ($480,000).
- Build additional features to make the website more usable (e.g. a reusable customer profile) = 10% of the business value ($240,000).
These metrics allow the organization to use Agile tools such as executive dashboards to track how much business value has been delivered – and how much is remaining – based on the amount of work completed for each of the actionable goals at the end of each iteration.
Using the above example, at the end of the second iteration, the delivery team advises that they have completed building the website structure (100%) and have also completed one fifth of the e-commerce capability (20%). Based on this status update, the organization now knows that they have received approximately $1.1 million worth of business value from the completed work45 – and that $1.3 million worth of business value is vested in the remaining work.
It should be noted that the above example is a simplification of the actual business-value calculations required in Agile approaches. The simplified model is intended to highlight the underlying difference between Agile tools and standard corporate reports. There are two areas in particular where the real-world application of Agile approaches is more complex than the example provided:
- The requirements listed in the bullet points above are too broad to be considered user stories (see Communicating actionable goals and priorities in Chapter 6: Business-value-driven Work for details on what makes an effective user story).
- The correlation between a partially completed requirement and its relative business value is subject to the nature of the work, for example a half-completed website may (or may not) be releasable in its current form. Therefore, the organization may prefer to calculate earned business value only on completed requirements.
Organizations need to use discretion when applying these calculations to ensure that the expected business value is not significantly over- or under-estimated, or misinterpreted by people who are less familiar with Agile approaches.
The requirements backlog is a simple reporting tool that enables both business owners and delivery teams to monitor the progress of work against the agreed business requirements (including activities) in each iteration. Although requirements backlogs can vary in format and complexity, depending on the nature of the work that the team is doing, the basic components of a requirements backlog are:
- A top-down priority list of the requirements that the team is scheduled to work on.
- Grouping of these requirements into iterations that indicate when the work for each requirement/activity is scheduled to be completed.
- Tracking the progress of each requirement by recording:
- when the work is actually undertaken
- the amount of work remaining to complete (i.e. fulfill) the requirement
- Graphical tools that visually depict the amount of overall work remaining for the delivery team and the estimated time in which the work will be completed (i.e. burndown charts).
Figure 4 shows an example of a simple requirements backlog.46
- Business owners are responsible for maintaining the list of requirements in top-down priority order.
- The business owners and the delivery team collectively determine the iteration in which each requirement will be delivered as part of the iteration planning session.
- Progress tracking on the work for each requirement is maintained by the delivery team through the day-to-day recording of their work in the delivery backlog. (Where the details in the delivery backlog are rolled up to provide the overall calculations used in the requirements backlog. See Tracking day-to-day work in the delivery backlog, below, for further details.)
The requirements backlog becomes a shared tool for all members of the Agile team (and their managers) to keep track of the overall status of their work. It combines textual detail (on the left) and visual indicators (on the right) to give the organization a ‘snapshot’ of the Agile team’s progress, at any point in time, without requiring the team to develop separate corporate status reports.
Chapter 19: Using Agile Tools provides a step-by-step explanation of how requirements backlogs are used by Agile teams.
The delivery backlog is a dynamic reporting tool that enables delivery teams to monitor and manage their actual day-to-day work in far more detail than the requirements backlog allows. Where the requirements backlog is a tool for business owners to record, prioritize and track the progress of business requirements overall, the delivery backlog is a tool for delivery team members to record and track their actual work and progress against the detailed tasks for each iteration.
At the end of each iteration planning session, the business owners and the delivery team agree on the subset of high-priority business requirements/activities that will be actioned in the upcoming iteration (i.e. ‘drawing the line’ in the top-down priority order of tasks).
These agreed requirements are transferred from the requirements backlog to a list of corresponding tasks in the delivery backlog, for the delivery team members to action. For example, if the entry in the requirements backlog for creating a new product sales tracking report is ‘design the tracking report’, the corresponding entries in the delivery backlog may be:
- Review detailed report information requirements with key stakeholders.
- Confirm that all report data is available in current corporate information.
- Design mock-ups of report layouts.
- Present report layouts to stakeholders for feedback.
The actionable goals that are listed in the requirements backlog become actionable work in the delivery backlog. These are the specific tasks that the delivery team will need to do in order to deliver each agreed requirement for that iteration.
Figure 5 shows an example of a simple delivery backlog.
The content of the delivery backlog is managed and updated by all members of the delivery team on a daily basis. Maintaining the progress information in the delivery backlog is not an added overhead for the delivery team members; it is an essential part of their own self-management. The fact that management and business owners can also use the delivery backlog tool (and the corresponding requirements backlog) to track the team’s progress is an added benefit from the delivery team’s perspective. It means that they will have little (or no) additional paperwork to complete at the end of each month.
Chapter 19: Using Agile Tools provides a step-by-step explanation of how delivery backlogs are used by Agile teams.
The requirements backlog and delivery backlog examples shown in the previous sections both include graphical charts, known as burndown charts, that indicate the delivery team’s progress (and effort remaining) for each iteration. This enables the delivery team to track the velocity of their work, as described in the Setting the next deadline section of Chapter 9: Immovable Deadlines.
In the requirements backlog, the burndown chart on the top right-hand side provides a visual representation of the amount of work (effort) that is remaining for the delivery team to achieve the minimum event requirements; the burndown chart on the bottom right-hand side provides a visual representation of the amount of work (effort) that is remaining for the delivery team to achieve all of the listed event requirements.
In the delivery backlog, the burndown chart at the bottom left-hand side provides a visual representation of the amount of work (effort) that is remaining for the delivery team to achieve all of the tasks within that iteration.
Combined, these burndown charts enable the business owners and the delivery team to track productivity rates (i.e. velocity) within and across iterations. This provides the Agile team with two valuable tools:
- A self-management tool that allows delivery teams to track their delivery pace during each iteration.
- An estimation tool that can assist delivery teams in determining the amount of work that they can reasonably expect to deliver in future iterations (based on the ‘yesterday’s weather’ productivity rates for work done by the delivery team that was of an equivalent size and complexity).
The In my estimation … section of Chapter 10: Management by Self-motivation described the powerful effects that can occur when delivery teams are empowered to manage their own work commitments. The use of velocity information provides a tool for these teams to confidently make estimations based on real accounts of their historical productivity levels (not ‘guesstimates’). It assures the delivery team that the work that they have committed to is achievable – and it generally results in far more realistic productivity levels in the actual work completed for each iteration.
The power of velocity tracking, however, is not limited to estimations of future work. It is an equally valuable tool for delivery teams to track and manage their work during each iteration against the levels of productivity that they committed to at the start of the iteration.
Tracking velocity in current iterations allows the delivery team to check its own status by comparing the level of outputs that they had expected to deliver (doing similar work) against the level of outputs that they are currently generating. If the delivery team is producing fewer outputs than expected, this may be a red flag for the team members to step back and see what might be causing this slowdown. For example, in the current iteration, business owners may not be as responsive to delivery team member questions as they had been in the past due to end-of-year financial reporting commitments. Equally, if the team determines that they are moving at a faster pace than expected, they may be able to confidently commit to a greater number of tasks at the next iteration planning session.
The content of these burndown charts can be automatically updated based on the progress information that the delivery team records in the delivery backlog each day. This enables the delivery team to review and track their velocity without requiring additional work to collect this information.
See Setting the next deadline in Chapter 9: Immovable Deadlines for further information on measuring a delivery team’s velocity.
In addition to progress reporting through requirements backlogs, delivery backlogs and burndown charts, Agile approaches provide senior management with executive dashboard reports that summarize the work within (and across) Agile teams for easy progress monitoring across the organization. Executive dashboards are similar in design to standard dashboards in corporate reporting tools. Corporate reporting dashboards provide management with an ‘at-a-glance’ visual summary of key activities in the organization (usually actual progress against financial KPIs). Agile executive dashboards also provide ‘at-a-glance’ visual summary information, but the focus is on measuring real productivity gains by summarizing the work completed and the work remaining for each Agile team across their iterations.
Figure 6 shows an example of an executive dashboard tool that management can use to monitor the progress of Agile work.
- At-a-glance core requirements: shows the progress of Agile work against each key executive-level objective for the Agile team.
- Requirements burndown charts: show the overall progress of the Agile team based on the amount of work that they have completed and the amount of work that is remaining against each milestone.
- Expected versus earned business value: shows the overall progress of the Agile team based on the business value of the work that they have completed and the business value of the work that is remaining.
There are other optional sections which Agile teams may choose to include, if they are relevant to the work that the team is doing, such as:
- A ‘work breakdown structure’ (WBS) that visually depicts the correlation and dependencies between each key executive-level objective for the Agile team.
- A ‘key information’ text area for other important status and context information that executives need to be aware of, including:
- key achievements
- key decisions
- known issues
- critical risks
Agile teams can adapt the executive dashboard for each initiative to suit the specific requirements of their work, the standards for the organization overall, or the preferences of individual executives.
As with the velocity tracking tools, most of the information in the executive dashboard tool is automatically generated, based on the progress information that the delivery team records in the delivery backlog each day. However, some of the optional sections (such as the WBS and the ‘key information’ area), where included, can require manual updating by the Agile team.
The WBS, which can be handcrafted by the Agile team at the start of the work, only requires updating when the status (or nature) of the key objectives changes – which is generally apparent at the end of each iteration planning session. The ‘key information’ area, however, may require more frequent maintenance based on the critical information that arises during the course of each iteration. In some cases, Agile teams have opted to link this section of the executive dashboard to a dynamic issues log that is maintained in a centralized area, which the Agile team updates every time key information arises (versus waiting until the end of each iteration to update these details). This enables executives to get a realistic ‘snapshot’ of the Agile work at any point in time, not just as part of their monthly reports. (How many corporate reports are you aware of that are able to give you real-time updates on the amount of business value that employees are – and are not – generating in their ongoing work?)
It is important to note that the example provided shows the work that is being tracked for one Agile team; however, executive dashboards can provide tracking information at any level of detail, including a visual summary of the work being done by all Agile teams.
The Early delivery means early payback section in Chapter 9: Immovable Deadlines explained that one way in which Agile approaches differ significantly from traditional business practices is in their ability to deliver business value to the organization from the first iteration. Because the work that the Agile team delivers is functional outputs (not thought papers or prototypes), the work that is delivered at the end of each iteration is often available for the organization to use immediately. This means that the organization can expect to receive early and ongoing benefits from their Agile work.
Similarly, the nature of Agile tracking and reporting tools means that the organization receives early and continuous status information regarding their Agile work. Management does not have to wait for a monthly report to know that there is substantial progress in (or key issues with) the work that the Agile teams are doing. The business owners and delivery team members do not have to wait until the end of the month to see status information that can indicate significant problems in the work that they are doing. Instead of status reporting being a one-off retrospective view of work each month, Agile tracking and reporting tools provide the team members (and the organization) with real-time feedback on their progress – and real-time flags when action is required.
The real-time tracking of work progress in Agile approaches provides the organization with another significant advantage over traditional business practices:
Immediate risk identification and mitigation. The benefits of using Agile approaches for risk management are not only evident in the work that the delivery team produces. The delivery of functional outputs forces team members to confront and resolve real issues in their work (see Mitigating risk in Chapter 7: Hands-on Business Outputs for further detail) – it is an inherent part of the nature of the tools that Agile teams use to track their work.
Key issues that can affect the delivery team’s productivity levels are immediately apparent in the tools that track the velocity of the team’s work. If the delivery team is producing outputs in an iteration at a significantly slower velocity rate than they did in a previous iteration with equivalent work, this could be a strong indication that the team is encountering issues that are limiting their productivity. Although Agile tracking and reporting tools cannot determine whether the source of the issue is a lack of skilled resources, insufficient participation from key stakeholders, inadequate tools or other organizational factors, they can prompt the business owners, the delivery team members or their management to take action to investigate the source of the problem. Furthermore, the real-time nature of these tools means that the investigation and mitigation did not need to wait until the end of the calendar month (or quarter) before being actioned.
The executive dashboard provides the Agile team and their management with tools for real-time monitoring of ongoing business value in the work that is being undertaken. This allows for risk management of a different sort: mitigating the risk that the organization’s resources will focus on work that brings relatively little business value, in favor of work that could deliver significantly greater business value.
Although the risk of low business-value work may not invoke the same sense of urgency that a critical issue would, it is one of those insidious problems that can slowly erode the value of an organization by chipping away at its real productivity levels.
Similarly, the executive dashboard allows senior management to view the relative business value of remaining work across Agile teams, to determine where ongoing resource efforts should be focused to provide the greatest benefit to the organization. It also provides executives with an exceptional level of accountability for the work that their employees are doing.
This accountability is not due to the fact that the day-to-day tracking of Agile work provides a ‘big brother’ opportunity for executives to track every detail of their employees’ work. In fact, Agile approaches can produce the exact opposite effect, by instilling an unprecedented level of trust in the work of their employees. It means that senior management can see at any point in time what the Agile team has produced – and the work that is remaining. They can know whether or not each Agile team is producing business value. They can confidently report to their executives about the work that their area is doing with documented proof for every claim. Most importantly, the information that senior managers are working from when making key decisions about the organization’s future, is a reflection of the real work that the organization has (and has not) achieved – far more accurate than a handcrafted (and strategically positioned) paper productivity report could provide. This means that the organization is better protected from the risk of executives making decisions based on faulty (or misleading) information.
Finally, there is the risk management that naturally occurs as a result of providing Agile tools that enable delivery teams to self-manage their work. The responsibility of estimating work, and then using tools to record the actual work against these estimates, compels delivery team members to try to make their estimates as realistic as possible. The delivery team knows that their ongoing self-management is contingent upon management’s confidence that Agile approaches are delivering business value to the organization. If they regularly overestimate their ability to produce valuable outputs, they run the risk of senior management losing faith in their ability to self-manage. If they regularly underestimate their ability to produce valuable outputs, they run the risk of senior management stopping their work because the projected business value of their scheduled activities is not producing enough ROI against the overheads of their resource costs. This creates an imperative for Agile teams to remain vigilant in their ability to accurately report on and deliver business value to the organization. The fact that the process is self-correcting can give senior management the confidence of knowing that risk is being actively managed at all levels of the organization.
43 The requirements backlog is known more commonly in the Agile world as a ‘product backlog’ because Agile approaches have tended to focus on the delivery of software products.
44 The delivery backlog is known more commonly in the Agile world as a ‘sprint backlog’ because in the Scrum methodology, where responsive planning is most commonly used, each iteration is called a sprint.
45 Based on 100% of $960,000 plus 20% of $720,000 ($144,000).
47 Adapted from simple sprint backlog example, courtesy of http://agilesoftwaredevelopment.com.