Before exploring the specific agile reporting methods, it’s important to return to the fundamental principles and understand our need for project status reporting. All Project Managers need to ensure that all stakeholders have the visibility of a projects status at any moment in time.
In traditional project management, we often spend a significant amount of our time either trying to plan our delivery programme or trying to track our path against these forecasts. We frequently find ourselves pitted against our own predictions as we report to our customers (“you said you’d be 47% complete, but you’re only 38% complete… what went wrong?”). It is not often admitted but traditional project methods lead to reporting that the PM and the team typically start out behind and in trouble and get progressively deeper and deeper into ‘delay’ demotivating the team and diverting the PM from productive leadership activities to justification and detail obsessive justifications.
Many businesses have invested significant energy in the creation of a Project Management Office (PMO) and have defined strict procedures for the reporting required to keep managers and other stakeholders informed. Past project failures, rather than pointing to the need for a new, innovative approach to project management, have instead led some PMO teams to apply tighter discipline to project reporting and change control. This often turns the project plan and the programme (rather than actual completed tasks) into the central indicators of project progress. Project failure is interpreted to prove that the process wasn’t rigorous enough. This forces PMs to include more granular task detail in their plans and risk registers turning them into project bureaucrats rather than team leaders.
Scrum Agile reporting techniques
The agile concept of “barely sufficient,” which we apply to project documentation, also applies to reporting; we need to keep the team and stakeholders informed on our progress, but it’s key to remember that we’re here to meet a projects success criteria, not to tick tasks off a list.
The reporting techniques we apply must concentrate on value delivered, in the form of features developed or requirements satisfied, and avoid getting us dragged down into the ‘task check-off’ mode that traditional methods often enforce. For businesses accustomed to a project plan, this becomes a cultural transition challenge as well as a simple project visibility issue; for PMOs and PMs comfortable with traditional tracking and reporting methods, new techniques can be disorienting and intimidating.
Using Scrum as an example, the reporting expectations are clearly defined; different agile methods have different standards. In Scrum, we typically create four reports at the end of each iteration:
- the Product Backlog, which lists all the features that make up the entire project/product
- the Sprint Backlog, which includes the activities we’ve committed to deliver in the next iteration
- the Changes report, which details the differences between the Product Backlog and the Sprint Backlog
- the Burndown report or chart, which illustrates (usually in the form of a trend graph) the work we’ve actually ‘burned through’ giving us a real-world view of the team’s progress
The Product Backlog is the master requirements repository for the entire project. All the requirements, or features, you’ve identified so far in your conversations with the project sponsor and other stakeholders are listed and prioritised here.
Unlike a comprehensive User Requirements Document, as seen in traditional project management, features requested are simply listed in a one-line description, and any elaboration or further definition, as discovered during conversations with customers, are kept separately from the Backlog and are typically “owned” by the designer who has taken responsibility for each feature. Backlog formats vary widely based on team preference but typically record at least the feature description, a relative size estimate, and some indication of priority. For more detail about Backlogs, read this Scrum Alliance’s excellent article.
In the effort to make agile seem familiar to customers accustomed to traditional project plans, the Backlog is often characterised as the project plan for the entire project lifecycle. Some teams – to satisfy their stakeholders’ desire to remain in the comfort zone of traditional practices – will use familiar tools such as Microsoft Project or Primavera to track the backlog, turning that tool from a task-focused to a feature-focused device. As long as project teams can resist the urge to start decomposing features into granular tasks and remain focused on the delivery of valuable features instead of task activities, this practice is encouraged.
Be resistant to making the agile migration into a cultural tug-of-war; the more agile PMs can utilise familiar tools without sacrificing agile concepts, the less resistance and methodology competition they’re likely to encounter. Tools such as ScrumWorks and VersionOne, which are designed specifically for agile development projects, are solid alternatives to Microsoft Project, with the added advantage of assisting PMs in educating and migrating stakeholders to agile terminology and concepts. Whatever tool is used, agile PMs must remember the central agile idea of simplicity and not make the Backlog more complicated than necessary; put simply, the Backlog is a list of requirements that stakeholders have told us they want. Many agile teams keep it on a whiteboard, or in Excel, or on the wall in the form of a bunch of sticky notes. In fact, sticky notes, which are easy to move, change, reprioritize, and even wad up and throw away, may be the representation of the Backlog most consistent with agile concepts.
In agile development, each iteration reveals new realities about the project, the processes, and the team’s capabilities and speed – that’s why the Sprint Backlog is such an integral element of the process. When we’re starting out, the initial Sprint Backlog tells us which features, out of all those uncovered, we’ve selected to tackle in the first iteration. As we work through our iterations and learn about the complexities, interactions, and realities of development, we modify our plans to take into account our empirical learnings about the product.
The Sprint Backlog is a subset of the Product Backlog, narrowly focused on the activities we’re trying to complete in the current iteration, rather than the entire feature set for the entire product. Stories to be developed in the current sprint are selected by the team, so that they own their commitments and are updated regularly in Sprint planning meetings to reflect the reality of the team’s progress.
As we’ve learned in traditional project work, teams can misjudge their ability to deliver or the complexity of features for many technical and organisational reasons. In addition, agile teams know that they, or their stakeholders, are likely to think of valuable additions or extensions to the project as they are exposed to it and have a chance to see how it works.
Agile teams are committed to encourage and create beneficial changes to the feature set in order to produce the end result that delivers the most customer value. We also want to avoid cumbersome change control processes that discourage change and make every new idea seem like a defect in requirements gathering. This is one area that plagues agile migration projects the most, as customers and development teams worry about our ability to control and track changes to a project in progress.
The Changes Report is a key instrument for helping teams and stakeholders gain comfort with the agile change process. True, we can add, delete, or modify features while the project is in motion, but we keep track of them in our Changes Report, and they are always subject to the approval of the Product Owner (in Scrum) or whomever is designated with decision authority from the client side.
Because this report often acts as a rough traceability document for audit or budget retrospectives, it’s probably better suited for a spreadsheet or outline list rather than a wall full of sticky notes. It should have enough detail to track the change requestor and the business justification for the change to allow stakeholders to make informed decisions.
While not included in every implementation of Scrum, it is advised to implement a Changes Report from bitter experience of disagreement and ‘convenient memory loss’ when changes requested by clients impact schedule or budget commitments.
The Burndown Chart is a simple trend graph that illustrates work performed over time. Agile teams use a relative-size approach (e.g., story points) to estimate the work to be done, plot the number of points developed as time passes (beginning with the first sprint and all features still to be developed), and draw a trend line between these points.
A quick look at the chart also tells us how far you still have to go; it can also indicate places where the team is getting stuck or incorporating lots of changes. Upward-sloping trend lines aren’t necessarily bad, as they can indicate beneficial changes in direction, but they’re always worth seeing.
This requirement for visibility is emphasized by the comments about “Big Visible Charts” made by agile pioneer Ron Jeffries. As agile PMs, our methods should always support the imperative for communication and collaboration. While conversation is the best vehicle for encouraging clarity and relationship, charts on the wall of a “war room” can make it clear to all who pass exactly what the team has accomplished, what’s left, and how you’re doing against commitments.
We’ll leave the conversation about the Daily Meeting for another day, except to say that, of all the reporting mechanisms of an agile team, it may be the most critical.
Agile teams should be agile in reporting as well as delivery; they can add charts for whatever they need to track, such as defects or customer acceptance, and can augment this minimum reporting set with reports on EVM, KPIs and others. Most important is to maintain open collaboration and communication and to avoid making the process more important than the product.