Velocity based planning for better forecast of your team’s work.
“How much to pull into the sprint during sprint planning?” In fact for me this is one of the most frequently asked question.
This question doesn’t have any answer in Scrum framework, this is more of tool/technique and strategy related question. Let’s explore various strategies to have better predictability.
Strategy 1: Pull around the average work DONE SO FAR.
In this strategy we find the total 100% work done and total sprints completed so far, this ratio gives us the average velocity of the team. During the sprint planning meeting pull +/- 20% of this average number.
Example: If the average velocity of the team is 6.5 Product Backlog Items (same size) then applying this strategy development team can pull 5 – 7 Product Backlog Items during their sprint planning.
This strategy would just normalize the work completed by the team over a period of time and is good for long time predictability for product owner for release scope or date calculation.
- At this velocity, my team has high probability of finishing 65 Product Backlog Items in the next 10 sprints
- At this velocity, my team will require approximately 6 sprints to finish 38 Product Backlog Items
Strategy 2: Pull around the average work done in the RECENT PAST
In this strategy we find the total 100% work done in the last 3 sprints and find the average work completed. During the sprint planning meeting development team pull +/- 20% of this average number.
Example: If the average velocity of the team is 7.5 Product Backlog Items (same size) then applying this strategy development team can pull 6 – 9 Product Backlog Items during their sprint planning.
This strategy would just normalize the work completed by the team for the recent sprints. Might not effective for long time predictability of release scope or date calculation, but will provide much better short term forecasting for product owner
- At this velocity, my team has high probability of finishing 22 Product Backlog Items in the next 3 sprints but over a period of 10 sprints they may finish 65 items
Strategy 3: Pull around long term MOST COMMON RANGE of doable work.
In this strategy we find the boundary conditions and remove them. This leads us to the long term most common range of doable work.
During the sprint planning meeting development team pull anywhere in between this range suitably decided with reference to people available and working days in the sprint.
Example: Remove the lower boundary 3 & 2, upper boundary 10 & 11. The remain indicates the long term most common range (4 to 9) then applying this strategy development team can pull 4 – 9 Product Backlog Items during their sprint planning.
This strategy would just normalize the work completed by the team over a period of time and is good for long time predictability for product owner for release scope or date calculation.
- At this velocity, my team has high probability of finishing minimum 40 and maximum 90 but most probably around 65 Product Backlog Items in the next 10 sprints
Strategy 4: Pull around minimum or optimum RANGE of doable work.
In this strategy we find the minimum and optimum range of doable work by the team
During the sprint planning meeting development team pull
- In the minimum range and later once they are done 100% they pull ready PBI during the sprint, reaching their best capability during the sprint.
- In the optimum range and later negotiate with the product owner if they can pull or drop the relatively lower priority work during the sprint to reach their best capability.
Example: Minimum range 3-4 PBIs, Optimum range 5-7 PBIs, then applying this strategy development team can pull minimum 4 Product Backlog Items during their sprint planning and later pull more based on their capability.
This strategy would be most ideal for those teams that are working with requirements that are more feedback oriented and having feedback accommodated in the same sprint would result in better ROI.
Over a period of time product owner can predict minimum and optimum release scope or date calculation.
- At this velocity, my team has high probability of finishing minimum 30-40 and optimally around 50-70 Product Backlog Items in the next 10 sprints
Use the best strategy based on your situation and acceptable predictability.
Comparing the velocity of the team, asking team to improve the velocity, demanding team to “commit” the items exactly equal to velocity all these kinds of indicate that the person has not understood the concept of velocity.
Velocity doesn’t guarantee the team’s work during the sprint, it’s a statistical data for better predictability. Naveen Nanjundappa
Certified ScrumMaster training shall explore many more such tools, techniques & strategies.
Register today or recommend CSM Training your friends & colleagues.
Share this article with your network.