Odoo CMS - a big picture

Estimation of Stories or Sub-Tasks?

What is the best estimation approach?

Bruno Gomes


How do you do the estimation of tickets in your sprint handling? 

By estimating the stories or the sub-tasks of this story? 

What are the advantages and disadvantages of each approach?

What is the goal of your estimation?

Why using Fibonacci approach?


In our current sprint setup, we use Agile - scrum with a length of 3 weeks main sprint (full development) and 2 weeks lazy sprint (improving automated tests, manual testing, fixing bugs, design and UX small improvements / fixes, translations).

Furthermore, we have the following structure of tickets:

Epic - we gather related stories in one epic

Story - a simple, clear and complete workflow of an user in the system

Sub-task - tasks that have to be done in order to complete one story

Here follows graphically a simple example about what we just mentioned above. Naturally every story would have more sub-tasks and specially much more requirements specification, but this is not the goal of this blog post. Here I am merely concerned about the difference of estimating sub-tasks or the whole story.

Odoo CMS - a big picture

Well, after creating the stories and sub-tasks to be accomplished, the development team faces the challenge of estimating what has to be done.

We use story points for the estimation.

I will also not discuss in this blog post if the best approach is by using story points or hours.


The goal of the estimation is to provide an idea to all stakeholder of the project (developers by itself, project managers, product owners, client, and so on) the size of the story.

The value of the estimation for the developers / PM is to see what we are able to accomplish during the sprint due to the capacity of story points of each sprint.

The value of the estimation for the client is to get a feedback about the value/effort of each story.


For the estimation, we use the fibonacci approach, where we follow the series (1, 2, 3, 5, 8, 13, 21, 34, 55). The benefit of the Fibonacci approach is that by using each, you don’t loose the feeling about comparing stories. I explain: when you estimate if the effort is 1, 2 or 3, it is fine. 2 is the double of 1, 3 is the triple of 1. So if you have a story which you consider 1, basically a story which is 3 means that is 3 times more effort.

But what about judging a story which is 22, 23 or 24? Hard no? You kind of lose the feeling of comparison.

That is why we use the Fibonacci approach, one story is either 13 or 21, but it could not be in the middle (15), in this way you can compare easier if one story is bigger than the other or not.


In certain sprint, we decided to estimate every sub-task of the story.


  • The development team felt more confident about the estimation since it is easy to break the big cakes in small pieces and judge the effort of these small pieces

  • The client had a feedback about each sub-task effort, and he could decide for instance to cut a requirement where the value / effort was not worth (one example, the client judge that the feature of opening a link in a new tab is too big for the value of it, so he cut the sub-task related to this feature)


  • The estimation took ages, image estimating every sub-task of each story


In certain sprint, we did other way round, we decided to estimate only the story.


  • The estimation was faster, we focused more on the big points, instead of considering every single detail of the sub-tasks


  • The client had no feeling about which part of the story he could cut, since we didn’t provide the estimation or the effort value of each sub-task


  • Either by using the 1st or 2nd approach, the estimations had the same quality in terms of correlation with the estimated effort x real effort.

  • The client prefers the 1st approach since he is the one paying for the features

  • The development team prefers the 2nd approach since the estimation was held not deep detailed


How do you do the estimation in your project? Stories? Sub-Tasks?

What other factors should be considered in order to have the best estimation setup and therefore plan the sprint capacity accordingly?

Do you provide feedback to your client? Do you judge it valuable?
I am looking forward for inputs. :)