Forecasting is critical to any project and can appear more complex when taking an agile approach. So you might be wondering…
How do I forecast my team’s future progress in Scrum?
We got you covered. This article will cover three essential topics to help you feel confident calculating your team’s progress into the future.
Story points are the most common strategy for sizing work in Scrum, and they size new work relative to past work. Connecting past and new work is critical to being successful at forecasting in Scrum.
Points are usually numerical values from the Fibonacci sequence, but teams can also use categories like t-shirt sizes of S, M, and L to size their work. Non-numeric sizing will need to be converted to numbers to calculate velocity and forecast future progress.
You can quickly do this by mapping Fibonacci numbers to the shirt sizes like an S is 3, M is 5 and L is 8. Some tools like Asana can automate this process for you.
If you’re new to Scrum and want to learn more about story points and relative sizing, check out my post on How to use story points in Scrum?
In Scrum, the term velocity refers to the speed at which a team completes story points over a period of time. Let’s look at an example.
Here are the story points a team completed over the last 4 sprints:
32 points
28 points
25 points
30 points
So we take those and average them.
(32+28+25+30) / 4 = 28.75.
This team has a velocity of 28.75 points. It’s also helpful to look at the standard deviation for a team’s past sprints. In this example, the numbers fall in a narrow range of 25 to 32. If the range were vast, the Scrum Master would likely need to investigate why before using the team’s velocity to forecast future progress.
When the team experiences changes, like new team members, the velocity will likely adjust as well. Next, let’s look at using the team’s velocity to forecast future sprints.
So why does velocity matter? It’s helpful when the stakeholder comes to the product owner and asks, “how long till the app is ready?”
We can look at what we’ve refined in the backlog, add up all the story points, and divide by the team’s velocity. The result is approximately how many sprints it will take to complete the features we currently have refined, assuming more aren’t added in the meantime.
This kind of forecasting is helpful in scheduling product launches with the marketing teams and managing dependencies. Suppose a specific feature needs to be released earlier. In that case, the product owner can re-order the backlog looking to ensure the necessary stories will be completed in time according to the current velocity.
A critical assumption when calculating velocity is that no new work is added during a sprint. Stakeholders can’t come and assign work to the team mid-sprint. Instead, they should connect with the product owner who can balance the request with all the other work in the backlog and adjust the forecast accordingly.
Some teams will be faster or slower than others based on their size, skill, and cohesion as a team. And that’s ok. It’s not always about quicker. We want teams working at a healthy and effective pace. I’d say, “think marathon, not sprint” but that gets really confusing with the Scrum language. 🙂
Seeing each team’s velocity is very helpful if you have to coordinate across multiple scrum teams sharing the same backlog.
Velocity will change over time. A newly formed team takes time to get up to its optimum pace. When a new person is added to the team, you should account for a slower velocity for a sprint or two. When road mapping across multiple sprints, you’ll want to take into account team member's requested time off because it may affect the velocity of a sprint.
By using user stories, you can say goodbye to the wasted time of working on the wrong thing.
Both story points and velocity provide transparent metrics for the scrum team to navigate the complexity of their assigned projects. They will be critical tools to roadmap the project and forecast future milestones.
I hope this article helped you learn how to forecast future team progress. If you want to learn more about Scrum in general, check out my What is Scrum? A Guide for Everyday People to Learn Scrum. If you have more questions, please feel free to reach out on LinkedIn.
Still not sure about your next step with Scrum? I offer a couple of free coaching sessions each month. You can signup for a free 30-minutes coaching session, and we can work together to identify a good next step for you.
They aren’t absolute measurements like hours or days but measure the amount of work a PBI takes relative to other PBIs. Typical measurements include using Fibonacci numbers or t-shirt sizes.
Learn to use story points and explore the essential Scrum glossary.
In Scrum, you are not measuring work in absolute terms like hours spent or lines of code to be written. Two reasons for this:
The problem with absolute sizing using hours is you begin to measure the people, not the work. Relative sizing measures the new work against past work shared by the whole team. Instead, the work is sized relative to past work already completed. So when looking at a new user story, the team asks, “Is this user story A most similar to this past user story B or this past user story C?”
Learn other essential Scrum terms.
The Fibonacci sequence is the go-to solution for many Scrum teams because it allows for relative sizing while still being a numeric measurement. It has two key advantages:
Non-numeric options are still possible, and one of the most popular is using t-shirt sizing, like small, medium and large. Lean more about using story points or learn other essential Scrum terms.
This measurement allows the product owner to forecast when future features will be ready. It is calculated by averaging how many points the team has complete over the past few sprints.
Learn to forecast in Scrum using velocity and explore the essential Scrum glossary.
Scrum is founded on three essential pillars, and each leads the team to ask a critical question.
Learn how to apply the three pillars of Scrum and then explore the most common terms in a Scrum glossary.
There are five values critical to the practice of Scrum: commitment, courage, focus, openness, and respect.
Learn how to align Scrum values with your organization and then explore the most common terms in a Scrum glossary.
The sprint goal encapsulates the product owner’s vision into a concrete statement for the development team to measure the sprint against. The sprint goal provides a theme for the sprint’s work helping the team see how all the parts come together.
Learn more about the role of the sprint goal in scrum and explore the essential Scrum glossary.
Scrum is founded on three essential pillars leading teams to ask the following questions:
Further explore the definition of scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
This is because Scrum’s simplicity makes learning easy, but Scrum truly changes how you work, and that adjustment can be difficult. It changes power dynamics and expectations within the team and between the team and the rest of the organization.
You can explore further is Scrum hard to learn, along with the pros and cons of Scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Scrum was initially used as a term related to project management in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka in their paper “New New Product Development Game” In the Harvard Business Review. The first recorded Scrum project came a little later in 1993 from Jeff Sutherland.
You can learn more about Scrum’s backstory. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Learning Scrum for the first time can be overwhelming. There are a lot of new terms and concepts in Scrum. I’ve listed the most common terms in a Scrum glossary.
What if you could turn those conversation into new clients?
Over 5 days, I’ll teach you how to use the power of story through a proven framework to craft the most profitable elevator pitch you’ve ever written.