If you are a scrum team member practicing sprints for some time then you may have encountered confusion around story points & velocity. Here are the few commonly asked questions –
Let’s clarify these concepts one by one. Firstly, let’s clear the confusion around story points. Story points is a famously used term to describe relative sizing. Where the points denote the complexity, uncertainty and efforts that a work item will take in comparison to the other work items. Nobody is stopping you from using points technique for work items other than ‘story’. Only thing you should do is stop calling it as ‘story points’ instead call it as ‘points technique’.
If leadership asks you about the backlog size then you simply can give them a sum total of points of all the work items. If they ask you specifically for work items of type stories or enablers or bugs then do the needful.
The points technique was initially found to signify that not everything could be factored in hours and days when it comes to software development which is not at all like assembly line. Points technique expects you to find a ‘base story’ which as its name suggests is a basis for starting the estimation process. This base story has a mutual agreement among team members and many times they keep many base stories to keep themselves aligned to their agreements on estimation.
Now it is time to unravel the fuss around velocity.
Velocity denotes the productivity of a team to deliver the valuable outcome measured at the offset of each sprint which helps us in knowing the following –
The velocity is NOT a measurement of productivity of only the development team but it is of the entire SCRUM TEAM who works together and incrementally finishes the outcomes to achieve the release goals. Also, it could be affected by the aspects which are not related to the project but the problems at the entire delivery layer or engineering mindset of the organization. So yes, if management wants a team to increase their velocity they should also be kind to find the reasons which are external to teams and may be causing hurdles.
What could be internal reasons due to which the team can not see improvement in velocity? These inconsistencies with velocity could happen due to the following aspects –
So the problem is not with the concepts but with the practices that we use to apply those concepts. Points technique has been found immensely useful in many complex environments and at times it becomes overkill when it is applied for the sake of applying since you want to label your project as ‘Agile’. Velocity is just a metric and not a KPI to measure an individual or team’s progress. We have often encountered environments where individuals are measured based on their story points completion per sprint. Well there are many ways to be ridiculous. We will just request to try others. 🙂
