5 Characteristics for Agile Reporting in the Real World
5 Characteristics for Agile Reporting in the Real World
Statistics can be a valuable asset to your Scrum team if you know how to wield them properly. Read on to see what one Agile Coach says on the matter.
Join the DZone community and get the full member experience.Join For Free
You've been hearing a lot about agile software development, get started with the eBook: Agile Product Development from 321 Gang.
Any Scrum Master or team member is keenly aware that they are expected to deliver software each and every iteration that provides value. Reporting, measurements, and metrics are vital parts of that effort, which, going forward, I will just lump together in only one term called "reporting." Some of us already know that reporting has been with us since before the dawn of software. We need reporting to help guide us, to alert us, to inform us when a change or course correction is needed. Without reporting we are running blind in the dark. Whether the organization you are working in runs 2, 3 or 4-week Sprints, reporting is as necessary as breathing air. Reporting is the direct result of the inherent need to measure, digest, and understand key data for decision making. In Agile, that reporting part must be quick and easy to get, read, and understand. Add to this the fact that in Agile you do not have time to build reporting during the execution of any iteration. That has to be already set up and available before the proverbial gun goes off at the starting line of the Sprint.
Reporting in Agile must help achieve results that provide value, period! Reporting must be accurate and as real-time as we can get it. Moreover, reporting also needs to alert us about any looming problems such as, 'the Team is going to finish the Sprint early because they didn't have enough work to do in the Sprint,' or when the Team is not going to complete all of the work in the Sprint because they were overloaded (i.e., forecasted with too much), or the Product Owner has added too much additional work (i.e., scope creep) to the Sprint that the Team will not be able get done. I have personally seen too many instances where the team's testing efforts in a given Sprint do not get finished by the end of the Sprint and now that testing work has to move somewhere else, mostly to the backlog. Reporting gives us the ability to track progress and pivot early on.
The Scrum Master and Team Members need to understand the overall health of the Sprint, how they are progressing towards achieving value, the team's overall workload, any outstanding impediments (i.e., blockers and dependencies), and individual work assignment. Moreover, Scrum Masters needs to know the Agile Team's Velocity and how they are trending towards completing Epics and Releases. It is important that these reports are detailed and yet easy to understand. As we progress up the food-chain the reporting gets more comprehensive. By the time we reach the Portfolio level in the organization all reports need to be clear, easy to read/understand, concise, and, most importantly, impart all necessary knowledge in less than 2 minutes. Two minutes? Yes, 2 minutes! At the Enterprise Portfolio level, senior management doesn't have the luxury of time to spend hours reading through reports. That level is under a constant barrage of time-consuming activities already. Good reporting must by definition be aimed at the correct persona with the correct context that is easy to read, understand, and act upon.
These Are the Five Key Characteristics to Consider for Your Report:
How does the report help you with your goals? Software is a major expense item now so when building software to sell on the open market (i.e., shrink wrap), to the medical community, financial industry, telecommunications, military weapons systems, or a host of other industries or paradigms, delivering it with value is paramount. The ability to keep and maintain pace with the speed at which the business environment changes makes reporting an imperative within Agile development. Good reports that matter are the ones measuring to see if you're heading toward or away from adding value (i.e., results). Reporting on results for how well the team is progressing toward Sprint goals, how many stories or bugs have been completed and how many are still left to do, are there impediments, and so on. Hence, align your reporting with your goals.
In Agile, the persona of the user consuming the reporting is important. Good reporting will need to be targeted for the correct audience with the appropriate content. The Agile Team, Scrum Master, Product Owner, Program and Senior Management are all users of reporting but need information at different levels with a different context. As mentioned earlier, the most detailed reporting happens at the team and Scrum Master level and each subsequent level above needs comprehensive and aggregated information. Hence, identification of the correct user persona is critical for reporting.
Does the report provide value? Or better yet, does the report address a pain-point that a user persona has experienced in the past and now reporting helps avoid those in the future. For example, reporting showing teams' historical velocity trends allows the Scrum Master to guide future Sprint commitments relative to past performance. Each report should provide value for the user's persona. If the report has no value then don't create it. Hence, measure and report what offers meaningful insight.
The best source of data is the one that is a single-system-of-record. Atlassian's JIRA Software is not only extremely popular but is an excellent tool for implementing outstanding reporting that is clear, concise, quick, and easy to understand in a single-system-of-record. Managing Agile development with this tooling is an outstanding way to track and report on your Agile development efforts at all levels. In fact, you can track nearly all aspects of your Agile development when properly configured. Hence, anchor your reporting to the right data source.
What is the frequency with which the report has to be created and delivered? The rate which this report must be produced (i.e., daily, weekly, bi-weekly, monthly, etc.) and or reviewed in the organization? The frequency of a report is important due to the basic need to be able to make a course correction if the data shows that you are heading off in the wrong direction. You must give the organization sufficient time to react. JIRA Software provides reporting at a myriad of levels from saved queries, Scrum Boards with built-in reporting, Dashboards, as well as Kanban Boards with built-in reporting. While all these reports are updated dynamically, not all need the attention on a daily basis. For instance, it is imperative to review the burndown daily (or multiples times a day) but a velocity chart holds relevance from Sprint to Sprint for planning and forecasting. Hence, finding the right rhythm of reporting helps you focus on the right information at the most relevant time.
These 5 key characteristics should be employed to the maximum extent possible in every organization and every report. Reporting must be results oriented to help achieve the goals. Metrics should never ever be used in a negative fashion such as implementing micro-management, performance evaluations for individuals, rolled up and used as a proverbial baseball-bat to hit Agile staff with, or for anything that will kill the team's morale.
Published at DZone with permission of Bryan McMillan , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.