If you’re using scrum framework in your software project, you would probably be familiar with the term “velocity”. It’s the measure of how much stuff can be done by the team in one sprint. It’s the total “points” claimed by the team at the end of the sprint after delivering production-ready stories. Some believe that this is a way to measure team’s performance.
Velocity usually varies from team to team due to the different style in estimating story points. In Midtrans, most of the teams use Fibonacci numbers to estimate the complexity of the story. Bear in mind that what we estimate is the complexity, not the time required to get the stories done. So, how the points weight can be significantly different depending on the team and the project.
For engineering/dev team, story-points system is a common practice. For Scrum Master, Project Manager, and Product Owner, this system is very helpful for planning and making promises to stakeholders. An experienced teams are usually able to estimate story complexity accurately, and maintain a stable velocity throughout sprints. So you can make release plan that can fulfill the needs of your customers without having to take its toll by pushing your team to work overtime for weeks.
However, when it comes to team who use kanban or work by tickets, sometimes story points & velocity are not needed or just don’t make sense. For example for merchant support team. They need to respond to & close tickets quickly, and sometimes it’s highly dependent to other teams. Not much can also be planned; there are mostly ad-hoc works. So in this case, story points system are irrelevant. Instead, they’re comparing incoming vs closed tickets to measure performance; and this is the right metrics to look at for their case.
What about data science project? After a year of managing a data science team, I think it’s hard to apply story-point system for an analytics or data science project. When it comes to building a mathematical model or analyzing data, there are too many possibilities. The data may not be ready for some reasons. You may need to do a long data cleaning works. Or maybe, you are not able to build a robust & accurate model even after months of iteration; because the problem is simply cannot be answered by the data you have. So this is the challenge that prevented me from using story-point system and measuring their velocity.
But most of the time, after the “science” part, there will be the “engineering” part. It’s the time to build the app to implement the model or visualize the result of their analysis. This time, the project becomes similar to software projects. So we should be using story-point system here. It may also make sense to start recording their velocity from this stage.
Thus, in my opinion, whether story-point & velocity will be useful will highly depend on the project. It’s nice to have some quantitative measure of performance to help you plan ahead & analyze the progress of the project based on data. However, we shouldn’t be blindly pursuing high velocity, because the most important thing to deliver is the business values, not the stories. In other words, when you’re delivering lots of stories and recording high velocities from sprint to sprint but the stories don’t actually provide business value, then all your work means nothing. So be agile and be sharp!