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 –
- On story points –
- What is it?
- Why couldn’t we have story points for tasks or bugs? or
- Why are we having story points for everything as it should be only for ‘stories’ as the name suggests?
- How many days is ONE story point?
- On velocity –
- How could we have consistent velocity with so many dependencies?
- Why is management pushing us to increase our velocity?
- Why is it considered as a measure of knowing the productivity of ONLY development team or say scrum team also? How about systems being responsible for degrading in velocity?
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 –
- How much scope could we finish as a team by a certain time?
- How much more time (in terms of sprints) will we need to finish a certain scope?
- How consistent are we as a team to derive such predictions (as mentioned in the above 2 points)?
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 –
- Poor Definition of Ready
- Definition of Ready or DOR helps us in ensuring that a work-item that we are planning to consider in a sprint will surely get finished in that sprint.
- But the work-items couldn’t get finished due to the bigger size of it. The practice should be breaking them into smaller items that could easily be executable within the sprint.
- Also, there are dependencies because of which a work-item though smaller in size gets dragged across many sprints because it depends on other items or other teams to finish their job. Hence it is important to check that box of ‘dependencies resolved’ before marking that work item ready for sprint
- Context Switching or Unstable team
- In many teams we have resources who could be fully loaded but due to resource crunch or urgency it rarely happens. It makes them unavailable to finish the work items and hence the actual outcome is not same as planned
- Poor Definition of Done & quality parameters
- Many times the bugs found could be avoided by effective coding and testing practices. Many times the work items are rejected by Product Owner or Tech experts because it breaks the other functionalities.
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. 🙂
