One of the most essential measures in Agile is team velocity. We rely on this size to determine how many tasks we want to complete in a given sprint. This, in turn, translates into the length of work on the entire project. The biggest challenge is to get a good team speed estimate early in the project. How can this task be made easier? About it in today’s post.
In this article, you will read about:
What is team speed?
To begin with, the concept of agile team velocity should be defined. It’s not easy because it’s not a conventional measure of how many points a team is able to achieve in a given sprint. Another question that arises concerns points. How do they define themselves? Where do they come from? Who broadcasts them?
Points are assigned to stories, which define certain functionalities in the finished product. Let’s say we are building an online store, and one of the functionalities is the possibility of ordering a product from the store offered to people visiting the store.
The story tells that the customer wants to buy a product from the store’s offer. This requires the implementation of a number of simple functionalities: button buy now, button add to cart, screen with a summary of purchases, connection to the payment system, creating a database with the list of orders and data for these orders, and adding an email notification system. Each functionality can be assigned a number of points.
Since the allocated points are a certain measure, it is best to allocate the simplest functionality 1 point, and then refer to the more complex functionalities to this simple. Let’s say our simplest functionality is to implement a button. We gave it one point. The summary screen may then have 10 points, the database of 30 points, adding 5 points to the payment system, and also 5 points to the mailing system. We estimated the total cost of implementing such functionality at 52 points. The big question remains: How many sprints does it take to implement the requirements in a 52-point story?
Use historical data
Every Project Manager knows that history is the most important thing. When starting work with a given team, or continuing to work with a given team, at the beginning of each project, we only have the history of previous projects and agile team velocity. Historical data is of course very helpful, but there are some pitfalls to watch out for.
First, you need to make sure that the composition of the project team is the same as in the projects for which you want to use historical data. Sometimes the change of one person on the team changes the velocity of the agile team dramatically. What technology will be used in this project? Same, different? How much different? Will the Product Manager be the same or different? Will the tools used in the project be the same?
These are just a few elements that may change and are worth paying attention to. Often, the Project Manager, seeing the unchanged composition of the project team, assumes that the agile team velocity will not change much since the last project. It’s easy to fall into the trap of making this assumption because, as I indicated above, the composition of the design team is not the only variable in the design puzzle.
Risk management when estimating agile team velocity
If we are unsure about the future, all we have to do is manage risk. The theory dictates that at the beginning of the project, we don’t know much about how smoothly the work will progress. So let’s assume, as far as we compare two similar designs, that the agile team velocity will be similar. Let’s assume that, as in the previous project, the team will have an average velocity of 20 points per sprint. The conclusion is that the above-mentioned story should be realized in two and a half sprints.
But let’s add an element of risk management to that. Assuming, in a simplified way, that it can work or not, the risk will be 50%. Of course, at the same time, we also assume a chance that it will go better than we also assume, equal to 50%.
Multiplying the estimated 20 points by 50% we define the uncertainty at the level of 10 points. This means that in the pessimistic variant, the agile team velocity will be 10 points, and in the optimistic variant 30 points. In other words, in the pessimistic variant, the implementation of the story will take 5 sprints, and in the optimistic variant less than two sprints.
Can you be more precise?
You can, but it takes a few sprints to see how the team actually works. How many points are earned on average in a sprint? Real statistics are said to start with five observations. In turn, from three observations, you can more accurately predict what will happen next. The most important thing, however, is to allow yourself that at the beginning of the project, our predictions about the pace of work may not correlate well with reality. With each successive sprint, it will be better, and the forecasts, even the long-term ones, will be more accurate.
