Selecting how much work can be accomplished in a sprint is one of the more difficult decisions in agile development. If you take on too much, you run the risk of stressing out the team and missing sprint goals. Take on too little and you risk under-delivering for your customers.
This is where velocity-driven sprint planning can come in handy.
By using actual data from past sprints to calculate velocity you can more accurately forecast your output and increase predictability for upcoming sprints.
If you’re looking to better understand how velocity-driven sprint planning works, the benefits of this method, and insights about how to make it work best for your team, this post is for you!
Velocity-driven sprint planning is a principle in agile project management that uses historical data from past sprints to estimate how much work will be accomplished in the next sprint. Velocity-driven sprint planning allows Scrum teams to estimate how much work can be delivered by a particular date.
Velocity-driven sprint planning is one of the two most common approaches to sprint planning, with the other being capacity-driven sprint planning. This post will focus on the former.
At a high level, the velocity-driven sprint planning process is pretty straightforward. The team selects a set of product backlog tasks whose estimates—calculated in story points—is equal to their average velocity. The individuals involved in velocity-driven planning are the Scrum Master, Product Owner, and all development team members.
In order to do this, however, first you need to calculate velocity.
Velocity is one of the key metrics in the Scrum framework and represents the amount of output a team can accomplish by the end of the sprint.
To calculate velocity you’ll need to assign ‘points’ for each user story the team has committed to. Note that when calculating velocity, only user stories that are completed earn points.
For example, let’s say you’re planning on a two-week sprint. Your point system may look something like this:
Once the sprint is over you’ll need to determine how many of the user stories your team committed to actually completed. Using the example above, let’s say the team completed 8/10 user stories.
8 users stories X 6 points per story = 48 story points
What you’re looking for is the average velocity of at least three previous sprints. So using the formula above, let’s say the following represent the last three sprints measured:
Note that in this example, the number of story points available in Sprints 2 and 3 is less than Sprint 1 because they had fewer commitments.
By adding the total story points and dividing by the total number of sprints (108/3), you can ascertain your average velocity of 36. Determining your average velocity is the key to effectively utilizing velocity-driven sprint planning because it lets you know, on average, how much you can get done in a given sprint. This can then be used as the indicator of how much work can be forecasted in a future sprint, thus giving a better signal of your team’s capacity and driving efficiency.
Of course, no sprint planning method is perfect. Here are a few potential issues with this method.
According to a ResearchGate study, velocity fluctuates the first few iterations because new teams are still getting used to the flow, or there may be changes to the team. The study goes on to state that velocity typically stabilizes after three interactions. Make sure to calculate story points using the method above with at least three to five sprints.
When it comes to user stories, there may be a significant difference in time to completion depending on the difficulty or complexity. So when a team gains eight points for completing a story, it may only have been a six or seven from a previous iteration, but velocity doesn’t have a measurement for partial points. Thus, there can be some incongruence in story points that will make your forecasting less accurate. Read about how to better weigh your story points here.
Velocity-driven sprint planning is still super popular within agile project management, and now that you know how to calculate velocity, let’s take a look at how to put the velocity-driven planning method into action.
Once you have the average velocity of a team, implementing this planning method is actually quite simple. Here’s the entire process laid out step-by-step.
If your team has the data, make sure to look at the average velocity from the last five sprints or more to get an accurate forecast as possible. No need to go too far back, though—data from two years ago is likely less relevant given technological and operational advances.
Once the average velocity is attained, simply choose priority items from the sprint backlog that are equal to or less than the average velocity. This process really only takes a few minutes to complete, which is why the next step is important.
While you could technically start your sprint after the second step, most agile practitioners would agree that it’s worthwhile to further define the tasks of the items you’ve selected from the backlog. During this step, the team uses the sprint planning meeting to discuss each of the selected backlog items to define the key tasks to completing each item. After discussion, the team can decide if the sprint looks full or not.
To finish your sprint planning strong, have your development team estimate their tasks in hours so you can get a firm grip on what your sprint will look like day-to-day. With this last step, you’ve now concluded the entire process of velocity-driven sprint planning.
One thing to note is that forecasting velocity will always be an educated guess for agile teams—there will almost always be variables that your model can’t quite account for that affect velocity. The best way to combat this type of variance is with data about the amount of work that’s done in a given time period.
To accumulate this data, it’s important to build a culture where developer velocity isn’t seen as a critique of someone’s work, and also doesn’t create unnecessary administrative tasks that slow down output. It’s a bit of an ironic scenario—you need data about developer hours in order to help your team be more efficient during their sprints, but you don’t want to slow down the team to collect the data…
7pace is a developer time-tracking tool built for agile development and project management that provides the best for developers and stakeholders alike.
On the developer side, 7pace integrates neatly into the tools they already use like Azure DevOps and GitHub. Rather than tracking their time as an afterthought with a yet another tool bolted onto their workflow, 7pace tracks their time in a totally frictionless fashion without interruptions.
For managers, 7pace provides full visibility into the work your team’s done, keeping everyone in sync and every project on track. Forget micromanaging your team with time log reminders and emails—7pace takes care of that effortlessly. Additionally, connect your time data to your other enterprise systems to provide deep insights about your production workflow and team performance.
Try 7pace Timetracker and see how it helps to improve your development team velocity and sprint planning.
By submitting this form I confirm that I have read the privacy policy and agree to the processing of my personal data for the above mentioned purposes.
Free eBook
Time tracking can actually be valuable for your team and your organization. But first, you and all your team members need a complete shift in the way you frame time tracking as part of your work.
Click the download button to receive your free copy of Rethinking Timekeeping for Developers:Turning a Timesuck Into Time Well Spent
Download Now
Your message has been transmitted to 7pace.
We will contact you as soon as possible.
Close
Your message has been transmitted to 7pace.
We will contact you as soon as possible.
Close
