How to Estimate IT Projects?

In our company teams are practicing Scrum, a well-established way of handling a project. Below you can find a simple explanation of how we perform backlog items estimation.

There is a precondition that has a serious impact on the quality of the estimates. The story should meet the DOR (Definition Of Readiness) criteria. It should also answer questions: why and what? Especially the “why” is quite important to software developers because it explains the whole context of the story.

What do we do during the Refinement meeting?

• The Product Owner presents and explains the story
• The development team gets familiar with the scope of a story and stakeholders expectations
• There is a space for Grooming (questions, clarification, doubts discussion)
• The Product Owner gets feedback from the development team (effort, raw estimation, the readiness of the story to be developed, split suggestion)
• The team can discover tiny things to do before Sprint Planning and thanks to that speed the next sprint planning meeting up, eg: check additional specification details, contact other teams to get desired “know-how”, check dependencies to other stories released by another team and do a quick basic technical research

There is a tradeoff between the estimation accuracy and the time spent on estimation. The more precise estimation is the more time it requires.

How do we estimate?

We do the estimation either during Refinement or Sprint planning (if it’s done during refinement then we just verify it during the Sprint planning).

The most important thing is that we do the estimation in relative terms instead of absolute terms. It’s a fundamental rule.

Relative estimation is the process of estimating task completion, not by units of time, but rather by how items are similar to each other in terms of complexity.

Benefits of using story points in Fibonacci-like style (1,2,3,5,8)

• it helps with relative estimation,
• you don’t have to focus on how much time does it take to deliver a story,
• it’s quick (estimation is related to already completed Product Backlog Items),
• this keeps team members focused on delivering value, not on the time they spend on it,
• helps to illustrate the velocity of a team,
• it’s impossible to play politics using velocity as a weapon,
• it’s accurate enough to plan sprints ahead,
• story points reward team members for solving problems based on difficulty, not time spent.

There are many methods that can be used for estimation. We are using the Planning poker technique. It triggers the team’s activity, starts grooming discussion, and therefore allows bringing a better picture of the story to the team. In the case of raw estimation sometimes we use the Big/Uncertain/Small estimation just to quickly give feedback to the Product Owner.