Before we explore specific agile reporting methods, it’s important to return to fundamental principles and refresh our motivations for project status reporting. No project manager (PM), agile or traditional, denies that stakeholders deserve visibility into the project for which they are paying and on which they are relying for added business value. Any disagreement is one of degree and focus.
In traditional project management, we often spend a significant amount of our development time either trying to predict our development path or trying to track our path against these predictions. We frequently find ourselves pitted against our own predictions as we report to our customers (“you said you’d be 56% complete, but you’re only 42% complete… what went wrong?”). One of the unspoken misfortunes of traditional project methods is that the PM and the team typically start out behind and in trouble and get progressively deeper and deeper into “task debt,” destroying the team morale and diverting the PM from productive leadership activities to justification and detail obsession.
Many organizations have invested significant energy into the creation of Project Management Offices (PMOs) and have defined strict guidelines for the reporting processes 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 Gantt chart (rather than actual delivered product features) 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 Gantt charts and risks 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 obviously need to keep the team and customer informed on our progress, but it’s key to remember that we’re here to build business value, 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 organizations accustomed to the project plan and Gantt chart, this becomes a cultural transition challenge as well as a simple project visibility issue; for PMOs and managers 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 product
- the Sprint Backlog, which include the features 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 effort. All the stories, or features, you’ve uncovered so far in your conversations with the product owner and other stakeholders are listed and prioritized here.
Unlike a comprehensive Business 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 developer 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 the Scrum Alliance’s excellent article.
In the effort to make agile seem familiar to customers accustomed to traditional project plans, the Backlog is often characterized as “the project plan for the entire release.” Some teams — to satisfy their stakeholders’ desire to remain in the comfort zone of traditional practices — will use familiar tools such as Microsoft Project 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, I encourage this practice.
I’m resistant to making the agile migration into a cultural tug-of-war; the more agile PMs can utilize 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 features 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 product, our 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 features 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 organizational reasons. In addition, agile teams know that they, or their stakeholders, are likely to think of valuable additions or extensions to the product 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, I favor the Changes Report from bitter experience of disagreement and “convenient memory” 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 velocity, Net Present Value, AgileEVM, or many other status items. Most important is to maintain open collaboration and communication and to avoid making the process more important than the product.
Get weekly PM tips in your inbox
TechRepublic’s IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!