Estimations are an important tool in Scrum. They help the Product Owner create a forecast of what the team can deliver and when. And it helps the developers understand how much work they can do in a single sprint. Then when is the right time to estimate?
Some strongly believe that the only moment when we should estimate is refinement. This happened with one team I worked with as a Product Owner. They would get very reluctant if we’d estimate a user story during Sprint Planning. However, others are estimating the work items in the planning session.
I won’t say there is a right meeting for the estimations. It depends on various factors. However, I want to be as prepared as possible for the planning session, so I prefer doing most of the estimation in the refinement. Yet, this doesn’t exclude the possibility of estimating some user stories in Sprint Planning.
Here is why I believe we can do estimation in both Sprint Planning and Sprint Refinement.
Why do we estimate during the Refinement session?
- The Product Owner has time to fill in the gaps in the User Stories
- We identify what User Stories we can split because they are too large for a sprint
- Helps the Product Owner forecast the future deliverables
Having this conversation in the Refinement session gives the Product Owner some time to update the User Story, to be ready for Sprint Planning. If it cannot be estimated, could mean it’s not clear enough
The team understands if a work item is too large to be completed in a sprint, so the Product Owner has the time to split it into multiple smaller User Stories.
Mature teams, teams that know very well the product, can estimate user stories for one or more sprints ahead. The Product Owner can then make a forecast and organize the next User Stories for the next sprints. It might be a high-level estimation that can change after the developers learn new things from the previous stories. But it helps the Product Owner draw a high-level roadmap.
When do we estimate in Refinement?
- We understand what the Product Owner requires
- The User Story has enough information and Acceptance Criteria
When the User Story is clear enough and well-understood by the developers. Even though a User Story might not be complete during Refinement, the context and what has to be done is clear, the Product Owner can update it as agreed with the developers and they can estimate it, anyway.
It’s extremely useful for a team to have a definition of ready to work items. Of course, we cannot know all the details from the start, but we need just enough so the team can deliver something of value.
What problems can appear if we leave all the estimations for Sprint Planning?
- We are not prepared enough for the new sprint
- It’s difficult to estimate User Stories in advance
Estimating User Stories is a start for a conversation regarding the completeness of the work item. If we start this conversation in Sprint Planning, we might realize that we actually have no User Story ready to be taken into the sprint.
The purpose of refinement is for the Product Owner to prepare all the needed information by the Sprint Planning starts. And if he doesn’t get the chance to fill in the gaps the team identified, we cannot include the User Story in the sprint.
The time doesn’t allow us to estimate User Stories in advance. We target all of our attention to that specific sprint that will start. That’s because besides estimating the User Stories, we might also have to do some other things: add subtasks to the User Stories, look at the capacity, and equally assign the User Stories among team members, discuss the sprint goal.
Why estimating in Sprint Planning is not wrong?
- Additional work can emerge before Sprint Planning
- They need more information after we discussed the item in Refinement
- Some items need re-estimation
Because we don’t know everything from the beginning, sudden information can appear between the two sessions. This may require creating a new User Story that wasn’t discussed in Refinement. If it contains enough details for the team to understand it, it’s a minor change or addition to the rest of the planned work, the team can estimate the User Story during Sprint Planning in this case.
It might happen after discussing a work item during Refinement, for the developers to need some additions to the information that was presented. The Product Owner might get that information right before the planning sessions starts. If it’s a relevant work item that is part of the sprint goal, here again, the team can take some time to estimate it.
Another thing that can happen is when the team gives an estimate of a User Story during Refinement. However, the team has learned some things during the current sprint that can change the size of a specific work item. It means they can re-estimate it during Sprint Planning.
How much should we estimate in Sprint Planning?
We dedicate the Sprint Planning session more to planning and organizing the future sprint based on the team’s capacity, and less to estimating the work. As a practice, I don’t encourage the Product Owner and the team to have over two User Stories left for Sprint Planning to estimate.
And we estimate in Sprint Planning only if we meet one condition. That being, the User Story has to be very clear to the team, and no other updates from the Product Owner are needed. This means that the work item should be small enough not to spend over 10 minutes discussing and estimating it.
Are there any exceptions to this “rule”? Of course, but we strive not to deviate from it. It’s counterproductive when something really important comes up to put it aside just to take it to the entire process in the next sprint. That item might bring a lot of value, so we try to be flexible, as long as it doesn’t affect the team’s productivity.
Can we include unestimated items in the sprint?
Only if the team is feeling confident that they have enough time to finish that work item without altering the sprint goal. Again, this shouldn’t happen on a sprint basis but should be something very rare.
It might be more common with teams that are just starting a new project and are in the learning stage.
For the rest, this should be an exception and allow it to happen only if that item is of great importance.
Final thoughts
So should we, as Scrum teams, have a rule that says the estimations are allowed only in Refinement? Certainly not. There has to be some flexibility, but be aware not to deviate from the Scrum framework. And when is the right time to estimate? As you can see, there is not only one right time to estimate in Scrum. If we need to do it outside Refinement, that’s acceptable too.
