In this blog post I will tell you how I’ve collected and used my Scrum team data to predict our deliveries and velocity.
One of the most important concepts in Agile methodologies is to deliver Value and deliver it constantly.
When discussing a new feature to be delivered for an end user, is kind of a big deal to know when the feature will be done and available to be used. Well, by its principles, agile will be adapting as it goes, and therefore updating with more precision after each iteration the delivery date of each small piece from the feature we are aiming at. If using Scrum, the question becomes: in which Sprint will each increment be done?
But, how is it possible to apply estimation without falling in a waterfall model (planning way ahead our project)? Even more, is it possible to bring precision in an estimation?
Well, let me bring some of the practices I’ve been applying in my Scrum Team.
A little of background:
I work as Scrum Master on a Scrum Team in S/4 HANA Cloud, we have 6 developers, a Product Owner, and a Scrum Master. The team is multidisciplinary, in other words, there is no specific frontend team, or backend, or even a test team. We are a Scrum team with only 3 roles (as per the Scrum guide): Product owner, Scrum Master and Developers.
We had a challenge of create a new project from scratch, and so the challenge came up: how will we know when each small piece of increment can be delivered?
To get an answer for such question, I started to collect the team data:
Before we get in the data work, I would like to talk a little about estimate.
In my Scrum Team we use Fibonacci sequence for estimate. Why Fibonacci and not hours? Well, we are trying to estimate EFFORT, and we are aware that it is not feasible (or possible) to have a perfect precision with estimate in software development.
Software development is such a complex activity that I dare to say that is almost impossible to know in the hour scale when each feature will be done. Therefore, we estimate! And as per definition, estimate is: "roughly calculate or judge the value, number, quantity, or extent of". So, Fibonacci sequence seems a good fit to determine sizes of effort.
After some Sprints (right after the team was formed, back in 2019), I collected the first set of data. It was not showing a very good consistency, as you can see per the below graph: Delivered Story Points per Sprint.
But, why was the Scrum Team having such a hard time to get more consistent results?
After some analyzes, two main reasons came up:
The first topic was fixed as the time went by and the team built up its chemistry.
However, the second one is a common issue on Scrum Teams: are the backlogs well described and well sliced?
To address such problem, a new approach was adopted by the Scrum Team: invest Sprint’s time into Backlog Refinements, this means dedicating some percentage of time for such activity. With that, developers got closer to business and product definitions, creating a holistic view of our product for the whole team. Also, better backlog items were created: more detailed and better sliced. With smaller backlogs is easier to create a constant pace for the team, if one Backlog Item is not done, it will be only a fraction of what was committed to be delivered, and therefore a slight downfall in the velocity.
After such behavior change, it was possible to see the difference on the Team Sprints of the following year. Below you can see the 2020’s Sprint Deliveries graph.
You clearly see that the velocity of the team starts get more constant, as the team creates its own pace.
OK, I got my team cadence now, but how is this helping me with the first question of this post? How am I being able to predict something with data from the past?
Well, by collecting such data, it was possible to create a mathematical function that, based on the historical data, can predict how much points of effort the team can deliver based on its availability.
In other words, I have found the teams velocity, and can “predict” how much effort the team could deliver per Sprint. Such prediction math function got an overall precision of 90% after 1 year collecting data! Such good precision its result of a Scrum Team with a constant pace, a very good health sign.
Going further into the requirements, by breaking down a Backlog in smaller backlogs items during a Refinement session, estimating them, and then with the team’s average velocity, it is possible to know when each small piece will be delivered.
Therefore, for me Refinement is key in Scrum, it helps to predict the delivers and get the team closer to the product.
But, what do you think? How do you measure your team’s velocity? Let me know in the comments!
Thank you for reading! I hope you enjoyed this post. Feel free to leave your feedback, questions, or comments below.
One of the most important concepts in Agile methodologies is to deliver Value and deliver it constantly.
When discussing a new feature to be delivered for an end user, is kind of a big deal to know when the feature will be done and available to be used. Well, by its principles, agile will be adapting as it goes, and therefore updating with more precision after each iteration the delivery date of each small piece from the feature we are aiming at. If using Scrum, the question becomes: in which Sprint will each increment be done?
But, how is it possible to apply estimation without falling in a waterfall model (planning way ahead our project)? Even more, is it possible to bring precision in an estimation?
Well, let me bring some of the practices I’ve been applying in my Scrum Team.
A little of background:
I work as Scrum Master on a Scrum Team in S/4 HANA Cloud, we have 6 developers, a Product Owner, and a Scrum Master. The team is multidisciplinary, in other words, there is no specific frontend team, or backend, or even a test team. We are a Scrum team with only 3 roles (as per the Scrum guide): Product owner, Scrum Master and Developers.
We had a challenge of create a new project from scratch, and so the challenge came up: how will we know when each small piece of increment can be delivered?
To get an answer for such question, I started to collect the team data:
- Sprint duration
- Team Availability
- Estimative
- Delivered
Before we get in the data work, I would like to talk a little about estimate.
In my Scrum Team we use Fibonacci sequence for estimate. Why Fibonacci and not hours? Well, we are trying to estimate EFFORT, and we are aware that it is not feasible (or possible) to have a perfect precision with estimate in software development.
Software development is such a complex activity that I dare to say that is almost impossible to know in the hour scale when each feature will be done. Therefore, we estimate! And as per definition, estimate is: "roughly calculate or judge the value, number, quantity, or extent of". So, Fibonacci sequence seems a good fit to determine sizes of effort.
After some Sprints (right after the team was formed, back in 2019), I collected the first set of data. It was not showing a very good consistency, as you can see per the below graph: Delivered Story Points per Sprint.
2019 Deliveries per Sprint
But, why was the Scrum Team having such a hard time to get more consistent results?
After some analyzes, two main reasons came up:
- The team was new, and therefore still finding the best way to work together
- The backlogs were not being refined enough
The first topic was fixed as the time went by and the team built up its chemistry.
However, the second one is a common issue on Scrum Teams: are the backlogs well described and well sliced?
To address such problem, a new approach was adopted by the Scrum Team: invest Sprint’s time into Backlog Refinements, this means dedicating some percentage of time for such activity. With that, developers got closer to business and product definitions, creating a holistic view of our product for the whole team. Also, better backlog items were created: more detailed and better sliced. With smaller backlogs is easier to create a constant pace for the team, if one Backlog Item is not done, it will be only a fraction of what was committed to be delivered, and therefore a slight downfall in the velocity.
After such behavior change, it was possible to see the difference on the Team Sprints of the following year. Below you can see the 2020’s Sprint Deliveries graph.
2020 Deliveries per Sprint
You clearly see that the velocity of the team starts get more constant, as the team creates its own pace.
OK, I got my team cadence now, but how is this helping me with the first question of this post? How am I being able to predict something with data from the past?
Well, by collecting such data, it was possible to create a mathematical function that, based on the historical data, can predict how much points of effort the team can deliver based on its availability.
In other words, I have found the teams velocity, and can “predict” how much effort the team could deliver per Sprint. Such prediction math function got an overall precision of 90% after 1 year collecting data! Such good precision its result of a Scrum Team with a constant pace, a very good health sign.
Going further into the requirements, by breaking down a Backlog in smaller backlogs items during a Refinement session, estimating them, and then with the team’s average velocity, it is possible to know when each small piece will be delivered.
Therefore, for me Refinement is key in Scrum, it helps to predict the delivers and get the team closer to the product.
But, what do you think? How do you measure your team’s velocity? Let me know in the comments!
Thank you for reading! I hope you enjoyed this post. Feel free to leave your feedback, questions, or comments below.
- SAP Managed Tags:
