Important metrics during an agile project
In Octobot we have a strong commitment with our clients time and expectations. Thus we use SCRUM agile methodology, to provide a fast time to market and fine tuning of features.
During the execution of projects we have tried to use different ways in order to measure the health of the project and we have come to a set of metrics that are useful for that purpose during execution.
Committed Work Vs Actual Progress
The first rule of thumb during a sprint execution according to the guide made by SCRUM founders, is not allow the Product Owner to change the scope of the sprint during execution.
Keeping that in mind is important to keep track of the Burndown Chart progress. There are important factors to watch in the progress of this chart, here are the most important ones from our perspective:
- Is important to understand the progress line of this chart and how much time keeps steady in an amount of story points. If this behaviour persist for more than one or two days you must raise a flag. This for example could mean that user stories are too big and the team is working in an epic and not a story, take note of this for the sprint retrospective.
- The progress line should go under the ideal line, if not the difference between both graphic areas can give you a measure about the delay of the sprint.
- Another important detail to take in consideration is if the progress line makes steep drops rather than more gradual ones. This mean that the stories were not broken in smaller pieces of work.
Team velocity is a metric that changes over time. As a team faces new challenges along different projects its synergy and knowledge grows resulting in a step up of the team’s velocity.
In order to have a reliable measure of this factor inside your startup is important to maintain team composition, any modification in the team will result in a change of the average velocity. And Remember every team’s velocity is unique.
This parameter is of paramount importance when forecasting sprints and helps the Product Owner and everyone else involved to have an accurate estimation of how many sprints will take the team to complete a Backlog.
For instance if the Product Owner has a backlog of 300 story points and the team can complete 50 story points in each sprint. The Product Owner can be confident enough to assume that it will take 6 sprint to complete the backlog.
Another important metric to keep track of during the development of a project is Quality. This is a critical factor to measure because it will define the outcome delivered at the end of the project and also is the result of the work made inside your startup.
Of course the best mitigation for bugs and errors is to create a complete suite of automated tests. In octobot for every user story developed we have one or more tests associated to the functionality developed that is one of the essential parts of our Definition of Done.
There are important questions to answer every time a sprint is finished:
- How many defects were found during development?
- Is the team documenting problems found during development?
- How many defects were found when released to the customers?
- How much code is covered by automated testing?
- How much value the outcome of the sprint add to the final customer?
- Is the Product Owner fully involved when scoping a new sprint?
This is a kick off of a series of post I will be writing about agile methodologies.
I hope this useful for you and feel free to comment.
See related posts
Writing Specification by Example Requirements with Gherkin
Tips for making the most out of the Specification by Example methodology with the Gherkin, a descriptive language used to write requirements.
Specification by Example: Fostering Collaboration in Software Development Teams
In this article we share our experience working with Specification By Example, a methodology that fosters collaboration among software development teams.