Best Practices How-To's Tips & Tricks

Our Approach to Estimation

Previous installments in the How We Scrum series include the Introduction, Our Scrum Roles, and Our Backlog. The fourth post is devoted to our approach to estimation.

Last year, we introduced the #NoEstimates approach to our Scrum process. Instead of using estimations and spent time to calculate the burndown, we track our progress based on the number of user stories we finish in each sprint. The main concept behind this approach is that our sprint goal is to deliver a set of user stories and it doesn’t matter how many tasks we need to complete to achieve this goal.

The benefit of this approach is that it reduces the amount of time spent estimating user stories and tasks during every planning session. However, it requires certain amount of experience and discipline from the team. We added a simple rule that helps us benefit from this approach: it cannot take longer than two days to complete any task. If the task requires more effort to finish, it should be split into smaller units of work.
We agreed that it’s absolutely fine to add tasks during the sprint, as we save time on planning session and don’t discuss every small unit of work in advance. The Scrum Master is responsible for enforcing this rule. If a member of the team reports work on the same task for three consecutive stand-ups, the Scrum Master asks this team member to split the task right away.


With the #NoEstimates approach, we track our progress over the number of completed user stories, so no estimation field is required.
Here is how we configured the YouTrack Scrum board to calculate a burndown based on user stories:

  1. On the Card tab of the Board Settings panel, set the Estimation Field to No Estimation field.
  2. On the Chart tab, select Burndown, set the Issue Filter to Custom, and set the Query to: Type: {User Story}.

User Story Based Burndown
There is also an option to calculate the burndown based on the number of resolved tasks (All cards). However, because we continuously add new tasks to the sprint, the Ideal Burndown fluctuates and becomes unusable.

Here is an example of a pretty balanced sprint with just the right number of user stories and tasks.

Task-Based Burndown
Previously, we used planning poker to estimate tasks. Now that we have more experience and know the velocity of our team, we have a good feel for the number of user stories we can finish in a sprint.
If you are new to agile, we recommend that you to start with a basic strategy for estimating tasks. After several months, you can give the #NoEstimates approach a try, if you feel that you are ready to benefit from it.

The next episode Our Sprint Planning is coming next week. Subscribe to our blog to stay tuned!

image description