How to Estimate User Stories and Plan Sprints
Particularly at the beginning of a Product Manager’s career, Scrum ceremonies and everything related to project preparation can be challenging. If you can relate to that, imagine the following scenario:
You just started working as a Junior Product Manager.
You’re working with a squad of 5 Engineers doing Scrum.
Your team has asked to discuss user stories from the backlog.
You’ve no idea about what you and your team are doing.
You’re attending your first backlog grooming.
After we discussed the first story, I wanted to move on to the next one, when I “suddenly” got asked by a developer:
“Don’t we estimate stories anymore?”
My first question in response to her was:
“Is this important?”
... you should’ve seen the faces of my team members 🤦♀️🤦♂️🙈
I’ve learned over the past several years that it’s important. Although I believe it’s important I’m not religious about it! Therefore, I want to share how we do it and how it helps me as a Product Manager.
Let’s Look at the “User Story Estimation Basics”
There are two agile frameworks most Software Development Teams work with these days:
Scrum and Kanban
The difference between these two is that Scrum is used as an iterative approach to work towards an MVP, MMF, or a goal, while Kanban focuses on continuous delivery.
Before I make things too complex or open up a religious discussion about “what’s better” or “when to use what”, I want to share two very simple and common examples for a typical Scrum and Kanban Team.
A Scrum Team usually works on a product or feature and iterates on it.
Example: Imagine the team at Instagram that introduced the “Stories Feature” on their app. They started with a simple story functionality, later they added filters, stickers, music, GIFs, and so on… a great feature in that app to iterate on.
A Kanban Team usually works as a service team that gets a lot of Ad-hoc requests.
Example: An Infrastructure team that grants permissions, and access to AWS, creates new environments, sets up technical dashboards, etc.
The performance of a Scrum Team is defined by its velocity while Kanban teams are measured by their throughput.
What’s the difference? 🤔
Calculating the Sprint Velocity Based on Estimations
In simple words, the velocity is the amount of work (number of story points) a team can produce or “burn” from sprint to sprint. This number is very important for Product Managers to be able to estimate or forecast when things can be finished, as long as all the other open stories are already estimated in the backlog.
Example:
You have a velocity of 20 story points per sprint and a feature backlog of 80 story points. That would roughly mean you can finish all tasks in 4 sprints.
However, this is not a guarantee because multiple factors can impact the team’s velocity. Development Teams use it to understand what they are capable of delivering in a sprint. Furthermore, it helps teams to understand which circumstances have an impact on it like people on vacation, wrong estimations, deployment issues, etc.
Sometimes teams plan their sprints after they have done the capacity planning, which is often a better way to foresee and plan.
The Sprint Capacity Depends Not Only on Estimated Stories
It’s very important to understand how much time each team member can actively work on tasks during a sprint. In this case, you need to look at how many hours each member is available in the upcoming sprint. In the beginning, we didn’t subtract time for meetings, vacations, or public holidays, which is a common mistake teams make. You don’t need to create a correlation between story points and hours. In the first place, you want to understand if people are fully available or on vacation, at conferences, in meetings, etc.
Here’s an example of how a capacity sheet can look:
Access and copy my capacity template here: 👉 click me 👈
Note: Don’t forget to check the capacity sheet during and after a sprint. Check if the original estimations were correct or not. You can do this, for example, during a retrospective.
To summarize with a quote from a great Agile Coach:
“The goal is to improve internal processes and ways of working to find the right capacity and with that to better predict velocity.” - Luis Gualberto
There is Throughput (Kanban)
Throughput, simply explained is the rate of things like tickets that are getting constantly developed. Another example can be the number of cars produced on an assembly line. In Kanban, you don’t iterate in sprints and you don’t estimate stories. Based on my example above, a Kanban Team doesn’t work directly toward a big goal. If you’re curious about this, you can read and learn a lot in the book Toyota Kata.
Note: Some companies/teams use Kanban to work on products, features, etc. I’ll write about that in a separate article.
...and Don’t Forget the Output!
This is what teams produce in a certain time period no matter what framework they use to operate. For example, checking the developed features, tickets, etc. over the last 3 months or even over the course of one sprint. That’s a lagging indicator that tells you what has been achieved in the past.
How to Estimate Stories in Scrum
After we’ve discussed all acceptance criteria of a story and understood how to solve the problem, including finding out the dependencies of a story, we estimate it.
If the team is ready to estimate we do the so-called: Planning Poker
The moderator of the session counts down from 3 to 1 and everyone in the team raises their hands or a card with the number of story points. Story points are segmented via the Fibonacci scale, which is between:
(small) 1, 2, 3, 5, 8, 13, 20, 40, 60, and 100 (big)
We look at 4 key things when we estimate tickets (WORD):
Work effort - Is it a lot of code that needs to be written or a lot of services that will be affected?
Overall complexity - Are there technical unknowns, or is it very old or poorly documented code?
Risk - Do we have dependencies on other teams? Is there only one person in the team who knows the code and needs to share the knowledge?
Deployment - Do we need to create new services? Can we easily deploy them?
In my current team, we focus on an average story size of 5 story points.
How long does it take to finish/“burn” 5 story points? 🤔
The answer is simple: We don’t know 🤷
What we know from our previous sprints and experiences (data) is that we’re able to finish 5 story point tasks within a two-week sprint. At the end of the day, it’s not about the days or hours per task, it’s about the team’s commitment to finish the work according to our definition of done.
These can, of course, be smaller or bigger. Everything, that’s bigger than 8 will be broken down into smaller tasks to avoid us not being able to finish it in our 2-week sprint cycle.
Every team estimates differently in terms of story points. The best way to get started with estimations is to “just do it”. Create a reference sheet with stories and the story points you’ve estimated in your previous sprint(s). Based on that sheet you can easily estimate new tickets for upcoming sprints. Just ask yourself if the new stories are bigger, more complex, more risky, etc., than the old ones in your sheet.
The tickets we estimate are User Stories, Tech Stories, and Tasks. Sub-tasks or bugs won’t be estimated and spikes will be time-boxed.
Why not estimate in hours or days? 🤔
Another option would be to estimate a ticket in hours or days. The problem though is that it’s hard to estimate the correct time needed for a ticket. Also, time estimation and team commitment foster an emotional attachment to a ticket that creates pressure on people which they shouldn’t have. Instead of focusing on time, people should and want to focus on good implementation. 🤓
How Ticket Estimations Help Product Managers
Next, I’d like to highlight some key reasons why estimations help Product Managers.
1. Understanding the Capacity and Planning Better
As much as companies like pushing for speed and fast delivery, the most important thing for Scrum Teams is to understand their capacity and the amount of work they can finish in a sprint, based on the available people. Every team will reach/discover a limit at a certain point. This can be helped by adding new team members or shrinking it down based on the team size, domain, skills of individuals, etc.
Note: Changing the team setup will trigger a restart of the forming, storming, morning, and performing process (Tuckman’s stages of group development). This can lead to a potential slowdown until the team starts performing again.
2. Be Able to Forecast Based on Estimations
A well-prepared and groomed backlog with estimated stories can help you to better predict when you’ll reach certain goals, launches, or milestones. Keep in mind that velocity isn’t a guarantee but a good indicator. If you work with customers, you negotiate deadlines. I recommend always adding a big enough buffer.
I suggest not planning too far ahead. Usually, we have up to 2 sprints prepared and groomed and a third that’s ready to be groomed. Planning further isn’t necessarily bad but can lead you into the situation where:
The scope of stories has changed due to the previous implementation. That means you’ll need to re-estimate again. (additional work)
Stories become obsolete due to the previous implementation.
People forget what’s been discussed and agreed on which will open up questions and discussions that’ve been done already.
Tools like Jira can predict outcomes based on story points and issues. It can accurately count when certain features (epics) will be finished. You can do the math by yourself by looking at:
The average velocity of the previous 3-5 sprints
The average issue count of the previous 3-5 sprints
Based on the estimated and un-estimated stories you can calculate how long it’ll probably take until all tickets are finished.
Simplified example:
Imagine your team works only on one particular feature over the next weeks/months:
Your average velocity of the previous sprints was 25 story points and the average number of issues/tickets was 7.
You’ve 15 tickets of 50 story points in your backlog and 7 other tickets that aren’t estimated.
Your customer asks for an ETA (estimated time of arrival).
If you apply the average story size of 3.57 to the 7 un-estimated stories you’d get 25 story points which equals one sprint = 3 sprints to finish the feature.
If you sum up the number of all the tickets, you get 22. That’s >= 3 sprints to finish the feature.
What to communicate to the customer/when will it be done? 🤷
On the one hand, it depends on your team.
What does your capacity look like?
Can they commit to it?
Does the team want to finish it in 3 sprints?
On the other hand, it depends on the customer.
Does the customer need the feature in no later than 3 sprints?
Is it already negotiated and a delay would imply a penalty or even losing the customer?
The math doesn’t answer these questions. I’d add a buffer of at least one sprint if possible considering the following scenarios:
Underestimation of the work
Technical and/or team dependencies
Deployment issues or freezes
Sick leave
Tip: Some people don’t include sick leave in their forecasts. Check out the average company numbers and add them on top. For instance, 1 or 2 days of sick leave per employee per month. That doesn’t mean every team member will be sick in one month. The idea behind it is to gain better planning security.
3. Less Uncertainty and Better Story Estimation
Being able to plan and forecast upcoming projects is very powerful. It helps me to
foresee and identify bottlenecks
prioritize better
negotiate better
communicate better
with customers and stakeholders.
Sometimes it happens that people want you to “squeeze” something in or change priorities. You can clearly visualize what’ll drop off if you decide to change them.
A mistake I often made was to push too many things and change priorities too often. This doesn’t only lead to the problem of not achieving goals and not finishing your sprints. Team members will become frustrated and the team’s mood will drop. You’ll also start losing your credibility. That doesn’t mean that you shouldn’t change them if needed. However, too many changes are an indicator of a lack of planning.
To be honest, If you have a couple of sprints prepared, your team works with a stable velocity, and the priorities are clearly communicated to all stakeholders… you’ll sleep way better. 🛌😴
There are many more things to say about Scrum, its planning process, and story estimations. Tell me how you work and benefit from it on Linkedin.
