Estimating Agile Projects using Velocity Game
Estimation is a hard practice to master, yet a crucial one in agile software delivery, esp. when you set out to start a new project in a new environment. Recently, we had a similar challenge in the redesign project of our Hepsiburada BuyBox Application, which ranks merchants for a specific product SKU according to several performance criteria.
The challenge here is that our team decided to use a brand new technology stack to cope with the technical requirements, and none of the team members had an in-depth knowledge in this new stack and the ecosystem comes with it. Furthermore, only one of the developers had an expertise in the BuyBox domain. So, we cannot use our current actual velocity (aka yesterday’s weather in XP), since it is heavily based on the Marketplace Order Management System domain, which is being developed in a totally different tech stack. On the other hand, we need a “reliable enough” project estimation, so that we can decide whether we should go with this project, if yes, what should be in the MVP scope, what should be excluded, whether we should reconsider our technical design, our rollout strategy, and so on.
So we needed an estimated velocity.
In this article, I’ll elaborate on how we estimated our velocity, and came up with a project plan that can be negotiable with stakeholders.
Velocity Game in Practice
Velocity game is a technique used to estimate team’s velocity, when you don’t have historical iteration data.
First of all, all stories were roughly written for the project, since we didn’t need to much story details at this phase. Then, the most experienced developer in the domain (which we had few 🙂) initially estimated all the stories. If you have more experienced developers, you might try the bucket game at this stage.
Later on, we gathered the team, laid out the story cards describing the relevant business/technical features, and hid the story points on them. At this stage, we found helpful to group the story cards into epics, which helps with the cognitive thought process as well as mix-and-matching the cards.
Velocity game is played in rounds. In each round, players (i.e. the team) try to estimate how much stories they can deliver in one iteration.
After laying and grouping the cards, Product Owner (PO) randomly selected a card, and both PO and the most experienced Developer told the story details to team members. Later, team started to discuss and decide whether they can deliver this story in one iteration. New cards were brought to team’s discussion until team said “there is enough room in the iteration”. When the first round was completed, PO noted the total Story Point number in secret.
This process was kept going until team’s estimated velocity started to converge to a number.
For example, here you can see that in the first round team was quite conservative about themselves, but in the later rounds their estimation started to wander around 36–37 story points. And we also realized, the discussions started to repeat themselves, since team members pretty much agreed on what can be included or what can’t be. So, we decided that no further rounds were needed and declared our estimated velocity as 36.
In order to have a healthy game, we tried the below techniques during our estimation. It might be useful for you, as well;
- try selecting cards from the same epics in a round,
- try selecting cards from different epics in a round,
- try different batches of cards in consecutive rounds,
- try reusing cards from the previous round in the following one,
- try mixing business and technical cards,
- question serial dependencies between cards,
- try replacing the exceeding card with a lower scope card, and vice versa, to determine the team’s limit.
Lastly, we added the contingency factor (e.g. known holidays, vacations, and unplanned day-offs), and calculated the project timeline using our estimated velocity. Using this estimation, we finalized the project roadmap and the priorities with the stakeholders.
Conclusion
By using the velocity game, we managed to come up with a sensible plan in a project developed in brand new technologies and in a domain that we are not accustomed to. In later iterations, team’s actual velocity started to build up, and we updated our project plan according to this.
Overall, thanks to velocity game, we determined the deadline in a pretty accurate way and we completed the project in the forecasted time.
After we completed the project, we did a timeline-based project retrospective, and we agreed on the value of having sensible and executable project plan was a great motivation for the team and gave focus to all of us during the project delivery. We were also happy about the informative aspect of the exercise in terms of understanding the project scope, potential pitfalls, and project dependencies.
Velocity Game led us to had a successful project adventure 💪
