The best way to do agile project reporting

Accurate reporting is a key element in fostering quality communication within an organization, especially large, complex, global enterprises. Without quality communication, employees have trouble distinguishing important from unimportant business data, especially those people like CEOs who have busy schedules. Regular status reports, including those that support quality assurance teams and processes, help ensure that everyone is doing work that is up to your company's quality standards. 

Effective status reports can be done at many different levels-- at the company level, department level, team level, task level, and individual level. The relevance of the information in a report can vary widely depending on your role in the enterprise but, in the right hands, status reports are invaluable in doing milestone analysis, that is, in tracking company performance, project issues and accomplishments, and pending work that needs to be done.

Less is more is a fundamental principle in gauging the appropriate level of reporting:  you should on only create enough reports to adequately track success and measure performance. Too many reports are a waste of time and effort--both for the writers and readers of the reports.

Reports should also pass the S.M.A.R.T test. The SMART acronym contains criteria to help set business and personal objectives, for example in project management, employee-performance management and personal development.  The SMART criteria calls for corporate, department, and team objectives that are:

• Specific – target a specific area for improvement.
• Measurable – quantify or at least suggest an indicator of progress.
• Assignable – specify who will do it.
• Realistic – state what results can realistically be achieved, given available resources.
• Time-related – specify when the result(s) can be achieved.

SMART criteria are commonly associated with the Management by Objectives (MBO) concept.  First made popular by Peter Drucker in the 1950s, MBO has fallen out of favor with many organizations because MBO has evolved into a top-down management concept that favors static, individual-focused metrics over dynamic, team-based metrics that encourage collaboration and creative thinking.  A traditional MBO approach often has top management defining an annual goal for the entire company and then handing out bonuses at the end of the year to people when the goal is achieved.  The problem with this approach is that it assumes objectives will stay constant over the entire year.  This may be case for some companies but not  for many or most companies, especially agile, responsive enterprises where work is dynamic and objectives change frequently.

OKR (Objectives and Key Results) is a goal setting framework created by Intel and used by several Silicon Valley companies including Google, Uber, Twitter, LinkedIn and Dropbox, among others.  Rather than applying a static plan with fixed yearly goals like MBO does, the OKR method is an agile, iterative approach to goal definition that uses quarterly (and sometimes monthly) goal cycles.

OKRs are not tied to individual performance. They're designed to tie team performance to company performance, allowing departments and teams to align to overall company goals. The most straightforward way to do that is by cascading the OKRs.  The company sets an objective and two or three key results, each business unit sets an objective and three keys results that supports the company, each team sets an objective and three key results that support the business unit.  Finally, at the individual level, each team member commits to personal growth that will allow him or her to be the kind of person who can meet the OKRs.

Here's an example of cascading OCRs for a hypothetical software company that has a goal of tripling the quantity and quality of software the company develops.

OKR Reporting on Agile Projects

OKR reports are designed to be public to all company levels —everyone has access to everyone else's OKRs and can see what they're working on (and how they did in the past).  When used properly, they help to reframe company-wide discussions from focusing on output (such as features created on product roadmaps) to outcome (business results).  In many ways, defining OCRs is similar to creating user stories on agile projects since user stories are intended to be "conversation starters" rather than detailed specifications for work being done by the agile team. In Scrum testing and methodology, the product backlog is a prioritize list of user stories that the scrum team maintains for each product. The backlog changes as business conditions change, technology evolves, or new requirements are defined.  Similarly, setting OKR goals also involves conversations about what matters, how each OKR will be measured and key results that are expected from each team. Like product backlog items, individual and collective OKRs are designed to be changed and updated to maximize business results.

One major advantage of OKR goal setting on software development projects is that it replaces the use of static performance metrics with dynamic, team-based metrics. This means that instead of committing to deliver a pre-defined business result by a specific date, a team can commit to iterate toward the agreed-upon OKRs.  This use of dynamic, team-based metrics dovetails well with several agile project status reports, such as the following Scrum reports that are typically created at the end of each iteration.

• the Product Backlog Report, a prioritized list of all the user stories that make up the entire product.  It captures all desired functionality for a particular release of software.
• the Sprint Backlog Report, which includes the user stories the team is committed to deliver in the next iteration (called a Sprint in Scrum).
• the Burndown report or chart, which illustrates (usually in the form of a trend graph) the work the team has "burned through," giving organizations a real-world view of the team's progress, and the
• Velocity Report--this is a report of how much the team gets done in an iteration, often measured in "story points" chosen by the team.

Product Backlog Reports

The Product Backlog Report is an ordered list of all things that need to be done within a project. Items on the list in Scrum projects are usually user-centric and follow a standard user story format that replaces traditional requirements specifications.  The most important items are shown at the top of the backlog report so the team knows what to deliver first. A customer representative (known as a product owner in Scrum) reviews (or "grooms") the backlog report before each iteration planning meeting to ensure prioritization is correct and feedback from the last iteration has been incorporated. The product backlog report serves as the main communication device between the development team and the customer/product owner, who can re-prioritize work on the backlog at any time, as well as add or subtract requirements as business conditions change.

Updating or re-prioritizing process for the product backlong report

Image Source: Archie1357

Sprint Backlog Report

The sprint backlog is a list of tasks identified by the Scrum team to be completed during the Scrum sprint. During the sprint planning meeting, the team selects some number of product backlog items, usually in the form of user stories, and identifies the tasks necessary to complete each user story.  Most teams also estimate how many hours each task will take someone on the team to complete.

The sprint backlog is often maintained using issue and project software program like JIRA, or via a group spreadsheet, or with sticky notes on a whiteboard (usually referred to a Kanban Board).  An example of a sprint backlog in a Kanban board looks like this:

Scrum Task Board

Image Source: Dr ian mitchell

Burndown Report or Chart

A burndown chart is a plot of work remaining to reach a given goal on the vertical axis, and time on the horizontal axis. Each point on the chart shows how much work is left to do at the end of that day (or week, month or other time period). A burndown chart typically has a line that runs diagonally from the top left to the bottom right corner that represents the estimated rate of work or "burn" needed to reach the goal.  If the line that shows the actual work done on the project is above the estimation line the project is behind schedule. If the actual line is below the estimation line the project is ahead of schedule.

Example of a burndown chart for an agile project

Image Source: Pablo Straub

Velocity Chart

The Velocity Chart shows the amount of value delivered in each sprint, which enable you to predict the amount of work your team can get done in future sprints. It is useful during sprint planning meetings, to help make decision about how much work a particular team should commit to.

Velocity charts can show the sum of estimates of the work delivered across all iterations 

Image Source: Atlassian

How OKR Goal Setting Is and Isn't An Agile Practice

Agile software development are all about building software products iteratively and incrementally.  One of the broad guidelines of the Agile Manifesto is to value working software over comprehensive documentation, since "working software is the primary measure of progress." Agile developers usually have learned the hard way that detailed documentation is wasteful and often can't be trusted because it's usually out of sync with the code it's meant to describe, especially on dynamic projects with changing requirements. Too little documentation is also consider a risk because agile developers (like all developers) need to know how to understand, maintain, and extend working software. (This is less of a problem on agile projects with integrated development and QA processes--such as those that practice Continuous Integration, or use software testing solutions capable of running executable specifications that can describe how the software is actually working.)

The less-is-more agile documentation concept is certainly worthwhile when trying to gauge the appropriate level of reporting to do.  Providing  customers, management and team members with progress reports that show you're delivering a large number of features in a timely fashion, however, should not be the primary focus of your reporting techniques. Contrary to what the Agile Manifesto says, working software is not the primary measure of progress on an agile project.  The primary measure, of course, has to be how well a project delivers business results, not how many features are developed.  The OKR goal setting framework described above is a great way to improve communication between teams and create alignment across different business units.  OKR complements Agile practices in several important ways, including by helping make it easier to prioritize the product backlog.  Tying a project to underlying business value is a surefire way to make sure your reports have a wide audience within your organization.

Related Articles:

• How to keep systems & teams in sync while managing requirements
• Key KPIs Across Agile Methodologies
• Techniques to scale agile across project teams and organizations