In Agile, time and again people ask this question "How would you estimate a release for a product?". When it comes from management they want to know the following:
- Calculate the man hours which is at their disposal to get to the release date
- Risk assessment
- How many people we need, can we expedite the development if we pump in more man power?
There are many more questions. In some cases they want to use some complex prediction algorithm to come up with the release date. Oh!! My god, I think, at the end of the day who is going to implement the features? Can an algorithm do an exact implementation? Can you use the available man hours?
I would say no. There is danger in using man hours. We don't take into account the diversity of a team. It can have people with experience levels. A person with ten years of experience may be able to finish a task in four hours, while another person with five years may take a day and someone less experienced may take two or more days. How does an algorithm include these differences? Or the team may be comprised of a tester, developer, BA etc. Each one has different work to do and you can't consider everyone to complete the different kind of work in the same hours at their disposal. Many a time management either doesn't understand or doesn't want to come out of its traditional way of running business.
There is an easy solution to this. No fancy algorithm, no man hour calculation, nothing. If you are aware of Agile concepts then what I am going to say may sound familiar. You can use the velocity of the team to come up with more accurate predictions. But before we see how we can predict release, we need to understand what velocity is.
Velocity is the story points a team can deliver in each sprint. A sprint can be anywhere between two to four weeks. I like to have smaller sprints of two weeks. Thinking that a sprint is of two weeks in length, let's examine further how velocity is calculated. Below is a table showing the sprint and the story points achieved in each sprint.
| Sprint # | Story points per sprint | Velocity |
| Sprint 1 | 1 | 1 |
| Sprint 2 | 3 | (1+3)/2 = 2 |
| Sprint 3 | 3 | (1+3+3)/3 = 2.3 |
| Sprint 4 | 5 | (1+3+3+5)/4 = 3 |
| Sprint 5 | 3 | (1+3+3+5+3)/5 = 3 |
So from the above table you can see how a team's velocity is calculated. In the first sprint (two weeks) it achieved one story point (SP). In the second it gained three SPs. So velocity is the total number of SPs achieved in all sprints divided by the number of sprints. In the third sprint the velocity was 2.3 and by the end of fifth sprint the velocity stabilized to three SPs. With that knowledge of what velocity is, let's tackle the problem of calculating a release date for a set of features.
There are two ways to do this. One is where the team has historical data to calculate velocity and second where the team is new and there is no historical data. Let's see the easy one first.
When the team has Velocity data?
This situation is applicable for teams that have been working on products for a long time and has historical SP data to calculate its velocity. The product owner gets a set of ten new features from the client and he wants to know how quickly the team can deliver these.
The solution is simple. Give the ten new requirements to the team and ask them to come up with estimate. Here is the process which needs to be followed.
- The team (dev, QA, BA) gets into a quick release planning (not really release planning) meeting with the product owner.
- The team and Product Owner (PO) go through the list of features and try to understand each one of them. There is no need to know the nitty gritty of the requirements as they may be pulled out in future. The team needs to get enough information so that it can estimate.
- Once the team has enough understanding about a feature it can estimate the user stories (features). The estimate is done in terms of SPs. The team plays planning poker. Below is the table showing the SPs estimated by the team for the features.
| Features | Story points |
| Feature 1 | 5 |
| Feature 2 | 3 |
| Feature 3 | 3 |
| Feature 4 | 8 |
| Feature 5 | 5 |
| Feature 6 | 8 |
| Feature 7 | 3 |
| Feature 8 | 3 |
| Feature 9 | 5 |
| Feature 10 | 2 |
- After all the ten features have been estimated calculate the total SPs for the ten user stories. From the above table the total SPs is 45.
- From the first table we know the team's velocity is 3 and the total SPs estimated for 10 stories is 45. If the team can deliver three SPs a sprint then to deliver 45 SPs it will take 15 (45/3) sprints. 15 sprints = 30 (15 * 2) weeks. 30 weeks = 7.5 months. So the team will take 7.5 months to finish the ten new features. To this you need to add the regression, stabilization and any other phases required for delivering a quality product. In essence the time taken is 7.5 months + Time required for Regression + any other stage.
- Follow the above steps from 1 to 4. Let's go with the same 45 SPs as the estimate.
- Now we don't have historical data to calculate the release date. What can be done? The team can decide and assume a number as its velocity. Say the team has decided two SPs as its velocity. Based on the team's assumption of its velocity you can calculate the release date.
- As the sprints end the team can start re-calculating its velocity and adjust the release dates.
From my experience a team reaches a stable velocity within four to six iterations. So in two months you can exactly predict the release date.
What happens if we don't meet the target?
During the release planning the team needs to fix dates on feature freeze and code freeze based on the overall estimate. By the time you reach the feature freeze date the team will have a good idea on whether it is going to deliver all the promised features. If the team is not able to keep the commitment -- if it has promised ten features and only eight will be completed --then the team members need not panic. The approach would be to ask the product owner to start negotiating with the client. Either the client has to accept the product with eight features or extend the time to get the whole set of features. This is quite normal and from my experience if you have a good product owner who has good negotiating skills the client will accept any of the above options.
Another advantage to Agile is that the client need not wait for years to get features. At the end of every end of the sprint the client gets a feature delivered. And I have seen except for few scenarios, client are quite accommodative. The reason is that client can see the ROI every two weeks and this actually builds confidence.
What happens if the client cuts short the estimate from x to y?
The answer is simple. You tell the client that X will be the time taken to deliver ten features and if you cut the time short then in Y time frame you can deliver only six features.
What happens if the client adds new requirements?
If the client adds more requirement and wants it in the same timeframe, then the team needs to tell the product owner that if you add new features then out of the previously committed ten features we may have to drop few to accommodate the new ones. This can happen only when prioritization comes into play.
The product owner and client need to decide the priorities for the features. Based on the priorities the team will tackle higher priority items first. Once the higher priorities are targeted it will pick up the lesser priority items. The product owner either needs to buy more time to include the new features or need to get few items off the list so that new items can be accommodated in the timeframe.
