Agile reporting for your projects

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

Product Backlog

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.

Sprint Backlog

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.

Changes Report

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.

Burndown Chart

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.

The Golden Rule: make sure you ASK QUESTIONS when you don’t understand something

I wore a full black tie and tuxedo to my first Nuclear Institute networking event when the dress code with Business Dress Code. Think about that for a second. The first time I ever met a lot of my peers in the nuclear industry I was the only man in the room wearing a tux when the rest were wearing suits and ties.

And yet, that’s exactly what I thought that I had asked been request to wear. I have photographic proof somewhere but I won’t make the effort to find it for this post. When I first heard my boss say “I am wearing black tie”, I was confused, a little worried, and even began wondering if my decision to join them at the event was a mistake. I also had to go and buy a tux as I didn’t own one at the time.

I was simply doing what he told me to do. I didn’t ask him why and I didn’t tell him it didn’t make sense to me because I’d seen photos of the event from the previous year and no-one was wear Black Tie formal dress. I was worried that it would look like I was pushing back and questioning him. I was afraid to make a bad first impression as I was new in the role.

Well I have news for you, when it comes to first impressions, wearing a tux in a room full of suits is a lot worse than asking a question.

Now, I could tell you that the reason I wore the shirt was because my boss had said that he was ‘wearing a black tie’ not ‘wearing black tie’. But the real reason is that I failed to take ownership of my own confusion and fix the problem. Had I done that, in a matter of seconds, I would have known to wear business dress. And my peers never would have had to ask me, “What’s with the tux, Andrew?” At my first day networking event.

As a subordinate, if something doesn’t make sense to you, ask. It’s really that simple. Just take ownership of the situation by asking a simple question. Clear up the confusion, solve the problem, and put yourself in a position to help the team, and your boss, be successful.

Plans vs reality and your expectations

I just wanted to put something out that I have heard a couple of times over the last couple of weeks regarding the responses that I hear from people (Project Managers mainly) when someone asks how a particular job is going. Whenever I hear this in a working environment I am always being told “ah there’s been a load of problems going on” or “I’ve been having to deal with a lot of issues” or “we’ve had to do X because Y has gone wrong”. You know what this really winds me up. From my point of view that is just day-to-day delivery. Things do go wrong. Things don’t go perfect all of the time. And I think that people sometimes just need to re-align their expectations. If you think that a job is going to go smoothly all of the time, every time…it’s not!

“that is just day-to-day delivery”

Maybe I’ve been lucky in the fact that I have been involved in sport all of my life in both team and individual sports and knowing that even the best laid plans go pear-shaped from time-to-time; for example in a cup final you may lose your key playmaker 20 mins into the game or have mis-underestimated the oppositions ability under the high ball or during an ironman triathlon your stomach cramps on the bike and you need to re-adjust your nutrition plan that you have spent weeks perfecting or you find yourself out of position on the swim or with a flat tyre on the bike. You always need to adapt and have plans in place for when things go wrong or at least precondition your mind to be able to think on its feet when met with a challenge.

If anybody asks me how my jobs are going at any moment in time my answer is usually “good” “fine” “as expected”. The performance may not be as planned, the customer may be continuously changing their mind, or even not know what they want. I may have issues with resources, material may not have arrived on time, things may have gotten lost but for me that is part of the day-to-delivery of any project. Now I’m not suggest that you bury your head in the sand or mis-inform. Things are going to go wrong that you need to raise as an issue and look for outside help you need to be quicker to raise bad news than you ever are at raising good. However, you are in place to do a job and to make sure that things happen and that the project is going in the right direction.

How can you expect to motivate a team without being a constant source of positivity and enthusiasm?

Project management is all about being an advocate for teamwork

When you’re leading a project, your best chance for success lies in how well your team works together. And as the project manager, you can improve team performance by making three changes.

The second change that you can make to help promote teamwork is by asking different teams to periodically share results and create new, self-sufficient teams.

This is essential because teams should be cross-functional, and have every skill needed to complete a project. Because it’s about the ultimate product and not just the team members themselves, diversity in skills, thinking and experience will help achieve better results.

And finally, help your teams to work better by reducing the number of members in each team. For most teams, 7 members (+/- 2) are ideal.

Why does a small team make a difference? Well, increasing the number of people involved in a team creates more channels of communication, which the brain can’t really handle. When we have to work too hard to figure out what everyone else is doing, people slow down.

You can put these actions to immediate action and become an advocate for teamwork throughout your project and wider business.

Project Management – Scope and Stakeholder Management

I strongly believe the project management can be defined by two things; Scope Management and Stakeholder Management.

Scope Management ; involves the clear definition of the works, the budget and the project outturn and success criteria. And the monitoring of management of this scope to ensure that the agreed outturn is delivered, no more no less.

Stakeholder Management; ensuring that all stakeholders are fully informed and bought into the progress and direction of the progress. This includes people from Customers, Sponsors, Boards, End Users, Delivery Teams, Governance and Regulators to name just a view.

This is, in my opinion, the Holy Grail of project management.