The Best Way to Do Agile Project Reporting
The Best Way to Do Agile Project Reporting
Learn how to use OKR methods to bolster your Agile framework and have clear lines of communication throughout the process.
Join the DZone community and get the full member experience.Join For Free
The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.
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 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 SMART 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 call 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 the 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 support 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 OKRs for a hypothetical software company that has a goal of tripling the quantity and quality of software the company develops.
Company OKR Example
Put people and systems in place for 3x improvement in quality/quantity of deployed software
IT, Operations Department OKR Example
Improve efficiency of technology infrastructure
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 OKRs 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 prioritized 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.
- 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 software release.
- Sprint Backlog Report - Includes the user stories the team is committed to delivering in the next iteration (called a Sprint in Scrum).
- Burndown report or chart - 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
- 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 the 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 requirement 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. The following is an example of updating or re-prioritizing process for the product backlog report.
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 an issue and project software program like JIRA, or via a group spreadsheet, or with sticky notes on a whiteboard (usually referred to as a Kanban Board). An example of a sprint backlog in a Kanban board looks like this:
Burndown Report or Chart
A burndown chart is a plot of work remaining to reach, with 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 another 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.
The Velocity Chart shows the amount of value delivered in each sprint, which enables 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 decisions about how much work a particular team should commit to taking on. Velocity charts can show the sum of estimates of the work delivered across all iterations.
How OKR Goal Setting Is and Isn't An Agile Practice
Agile software development is 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 considered 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 making it easier to prioritize the product backlog. Tying a project to its underlying business value is a surefire way to make sure your reports have a wide audience within your organization.
Published at DZone with permission of Francis Adanza . See the original article here.
Opinions expressed by DZone contributors are their own.