Recently at Nineleaps we worked on a project that required agile governance to help us make right decision and ensure successful sprint completion. After analyzing the project closely, considering what key stakeholders need and understanding multiple iterations of different metrics used, the team finally shortlisted 5 metrics to get visibility across sprint governance. These metrics allowed stakeholders to evaluate the progress accurately and take timely corrective measures wherever required.
I am sharing those 5 agile metrics in this blog that helped us successfully govern the progress across various levels.
#1 Task status pivot
To visualize remaining work in development for each story, a pivot chart is made from the sprint task data. In this pivot table, stories are listed in rows, status in columns and the number of tasks as value. This data provide details about the number of pending tasks required to complete each story.
Task status pivot offers a snapshot of the current state of software development life cycle (SDLC) for each story. This visibility allows software team to plan, prioritize and distribute tasks as per project requirement.
#2 Area wise progress
The second pivot to follow is area wise progress where data is categorized as per area and difficulty is listed in rows, status into columns and number of tasks as value. While the first pivot provides visibility into the progress of the story, this offers complete insight into various areas of development within a story including frontend, backend, DevOps and automation.
Similar, to the earlier pivot this helps team identify which area requires more effort, allowing them to plan and prioritize for successful execution of sprint.
#3 Remaining effort
Nineleaps has a different way to depict the burndown charts without estimating the task in hours. Here’s how we do it — For each task, we assign a relative score based on the level difficulty. For instance, a task with high level of difficulty would be given a score of say 10. Once we designate a relative score for all the tasks, we calculate the sum of all sprint tasks, which represents the total outstanding effort or the total work load for the sprint.
Categorizing tasks into high, medium or low buckets significantly reduces systematic underestimation of tasks. Here we represent high risk/difficult tasks in a non-linear way. This means if the team works only on easy tasks, the burndown line will be above the ideal line, offering complete transparency into outstanding work and allowing team to channelize efforts in completing the sprint as per schedule.
Capturing and responding to the blockers is as important as knowing the state of the sprint. At Nineleaps, we use the following parameters to capture and represent details of the blockers:
# of Tasks Blocked
# of Blockers
# of Blockers resolved Today
ETA for Blockers
This metrics makes bottlenecks and blockers visible, enabling stakeholders to analyze, plan and resolve these tasks to ensure timely completion of the sprint.
#5 Bug analysis
Analysis of the bugs raised during the sprint plays a key role in agile governance. As the stories develop and are released for testing, we use the following metrics to capture and track bugs.
# bugs raised towards each story
# bugs with higher severity that is not resolved
# total bugs created, resolved and closed
This not only allows the team to understand the frequency and severity of the blocker bugs affecting the performance but also assess the quality of the sprint progress.
Using these metrics have helped all the stakeholders across the project know the exact state of the sprint at any given point. These metrics have dramatically improved predictability and reliability of the sprints. And therefore, at Nineleaps we are encouraging the other project teams to use this governance mechanism to ensure successful completion of sprints.
Please share your thoughts and comments on this governance system and I will be happy to know what other metrics you are using for agile governance of the sprints.