Best Practices How-To's Newsletter 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!

Comments below can no longer be edited.

4 Responses to Our Approach to Estimation

  1. How we Scrum in YouTrack Team | YouTrack Blog says:

    January 26, 2017

    […] Defined procedures for estimation and planning. […]

  2. Avatar

    Russ Egan says:

    January 26, 2017

    Is your 2-day time contraint on *tasks* or *stories*?

    We’ve been using stories-completed for our points too, for a while now. And we do a similar time contraint: stories must be complete-able in a single sprint (1 week).

    But if only tasks have a time constraint, and not user stories, don’t you find that story burndown velocity is inconsistent? Since some stories can be big and some small? I’d think burndown based on story *points* might be a better measurement.

    I suppose task burndown might work too, but since you can add tasks during the sprint, that wouldn’t give you the measurement you want.

    • Valerie Andrianova

      Valerie Andrianova says:

      January 27, 2017

      Hello Russ,

      Our 2-day constraint is applied to tasks only. Since we don’t estimate User Stories and tasks, it doesn’t really matter for us how many tasks we need to get done in order to complete a user story. Yes, story points based burndown can be a better measurement, if you use story points. I think #noestimate approach works for us because we are experienced enough to feel our velocity. Also, we don’t use Burndown as a measurement, it just helps to keep track of our process during the sprint, not more. And we are ok with moving uncompleted user stories to the next sprint. It does happen sometimes.

  3. Avatar

    Georg M. Sorst says:

    September 9, 2019

    Hi Valerie,

    just came across this, and being avid Jetbrains fans we thought we could learn a few tricks from you 🙂

    A few questions came up while discussing this with the team, maybe you can provide some pointers:

    * When doing the Sprint planning, how does the team decide how many User Stories are added to the Sprint (since User Stories can wildly vary in complexity)?
    * When splitting a task, are the resulting (smaller) tasks done right away or in the next Sprint?
    * How and when do you decide how to split tasks? Eg. right after the daily stand-up when the Scrum Master determines that the two days have been exceeded?
    * And who decides how to split the task? The developer, tech lead etc.?
    * Do the tasks always have to result in a deployable state?

    Thank you!

Discover more