We’re always exploring ways to enhance our platform and keep our partners in the loop about the changes we’re making to help them grow their dating businesses. That’s why we use velocity as part of our Agile process.
Velocity represents how much can be delivered within a particular sprint and therefore how quickly a project can be delivered. Velocity is calculated using story point values which represent the scale of difficulty or amount of effort required to complete each piece of work in a team’s backlog. A scrum team attributes story points to a particular piece of work; in our case we use 0, 0.5, 2, 5, 8, 20 and ‘?’, using ‘?’ to indicate that the scope of the work is currently unknown.
Velocity can be different from team to team but allows a Product Owner (PO) to plan when certain features will be released. For example, if a team’s average velocity is 20-25 story points per sprint, POs can review what is in the current backlog for a given project and estimate, roughly, how many sprints it will take to complete all the work. If adding a new photo upload feature equates to 100 story points, using the example above, we can estimate that it will take four to five sprints (eight to ten weeks) to implement the new feature in its entirety.
Ideally this estimate will include releases of smaller parts of a particular feature throughout the sprints. This is so that we can make small changes to the overall feature as we go, based on feedback from key stakeholders. This feedback will then help us to plan our next steps and determine a clear end goal.
Measuring velocity also gives each department the opportunity to plan work depending on when something is forecast to be released. Our CRM team might need to schedule an email campaign to promote a certain product or the partner team may need to advise on advertising strategies based on upcoming releases. Velocity helps us do that effectively.
It can take some time for a team’s average velocity to be established, especially in extenuating circumstances such as emergencies or interruptions, changing of team members and a and lack of experience in a scrum or agile environment.
Now we’ve got emergencies and interruptions covered, we’re focusing on optimising our overall process, and stabilising our team formation. That means we’re now in a better position to start using team velocity in a more meaningful way.
As well as predictability, a whole host of other team performance metrics can be borne out of velocity. Our next objective is to be able to give a solid prediction for when a feature or particular set of stories (not necessarily one product) will be delivered.
For more information about what our development team are working on, check out our latest product update.
Alex Osborne, Project Manager at White Label Dating®