Al. Zwycięstwa 96/98, 81-451 Gdynia, Poland
+48 58 782 45 40 / +1 206 357-8481
office@soldevelo.com

Project estimation in an Agile team. Methods and techniques.

Project estimation banner

One of the best practices in project management is the proper task estimation. In agile teams, there are different types of estimation techniques. Regardless of size or budget, estimating a project can be a daunting task. At an early stage of the project’s life cycle, requirements are poorly-known and less information is available to estimate the time needed to spend on the project. This is why various estimation techniques were created and are available to use by Scrum teams.

Below, you will find 3 different methods of improvement in the project estimation process.

Find out which of them can prove the most suitable for your team!

 

Planning Poker

 

This is one of the most recognized techniques of team effort estimation all over the world. The planning session begins with the Product Owner’s description of the User Story that has to be estimated.

Each team member, including the Scrum Master, can ask questions, to understand the discussed Product Backlog Item better. After an explanation of the Story’s assumptions, the Team starts the first round of estimation. Every person receives a set of cards depicting a sequence of Fibonacci numbers (each subsequent number is a sum of the previous two).

The number that is the best reflection of the size of the discussed Story should be chosen, and the card should be placed on the table upside down.

By the “Size of the Story”, we should understand the amount of work needed to deliver it = effort. Then, on the Scrum Master’s signal, everyone reverses their card. People who chose the lowest and the highest numbers have to explain their choice. Then, others join the discussion and draw conclusions together on what could be delivered faster, and what parts need more effort put into them.

You can make the Planning Poker cards by yourself, order them at one of the big online shops e.g. Amazon or use a mobile app from Google Play:

https://play.google.com/store/apps/details?id=artarmin.android.scrum.poker&hl=pl.

After the first discussion, the team conducts another round of estimation until an agreement on the final size of the story is reached. This SIZE is called Story Point. Story Points describe the level of complexity of an element and the amount of work required to implement a given story.

 

REMEMBER — the PBI may be considered as extensive not only because it is complex. If it takes a lot of time to deliver the result, e.g. a simple task needs to be repeated a hundred times, it is also qualified as laborious.

 

To play Planning Poker in a distributed team, it is best to use:

https://www.planningpoker.com, https://www.planitpoker.com/.

 

Does playing Planning Poker really work?

Yes but only if it is used systematically, sprint by sprint. In the beginning, team members may be skeptical because estimating in Story Points seems to be too abstract. But the longer it is used, the more accurate the estimates become.

 

A short guide on how to play Planning Poker:

 

 

Team Estimation Game

 

It’s an alternative to Planning Poker, as the method is not without its flaws. The three most significant disadvantages of Planning Poker include:

  1. False start -> a team member turns his card too early, so he can suggest the answer to the rest.
  2. Three or five Story Points? -> it takes too much time to discuss minor differences between estimations.
  3. Too abstract Story Points -> so developers can try to convert Story Points to simpler units.

The Team Estimation Game can be a better choice for non-experienced teams.

 

How to play the Team Estimation Game? 

  1. Prepare and print User Story cards and place them according to their priority in the Product Backlog.
  2. Put the first card on the table and decide which side of this first card (left or right) is for stories with higher priority, and which is for those that are less important.
  3. The game beginner takes the first card from the deck and puts it on the proper side, left or right.
  4. The next player repeats the action and takes the next card or rearranges cards that are already on the table.
  5. The game continues until every story is estimated thus.
  6. Each decision has to be clarified: Players explain each choice on the fly.
  7. When all cards are placed on the table, the team assigns numerical values from the Fibonacci sequence to the stories.

 

The Product Backlog is a living artifact, so a user story can be added there at any time. Estimations from the last Team Estimation Game can be a benchmark for new cards.

 

Pros of The Team Estimation Game:

  • Estimation based on comparison is easier to understand;
  • Each User Story is estimated multiple times;
  • This format is more appreciated by introverts.

 

Ideal hours

 

This technique tries to estimate the productive time necessary to spend on the project. Based on these calculations, the team plans its work. It is said that during the 8-hour working day, only 4 to 6 hours are productive. The rest of the time is spent on phone calls, responding to emails, and so on.

To calculate the team’s possibilities, that is, how many effective hours there are in one Sprint, we have to multiply the number of team members by several effective hours spent during one working day and by the number of working days in one Sprint.

Example: 

4 developers x 5 ideal hours x 10 days (2-week Sprint) = 200 ideal hours

From the final result, one has to subtract the time spent on daily meetings, holidays, unexpected days off, etc.

Daily Scrum: 

4 developers x 10 days x 0,25 hours (15 minutes) = 10 hours

Sprint Planning: 

4 developers x 4 hours = 16 hours

Sprint Review: 

4 developers x 2 hours = 8 hours

Sprint Retrospective:

4 developers x 1,5 hours = 6 hours

Backlog Refinement:

4 developers x 10% of the Sprint length (1 day = 6 hours) = 24 hours

It means that from the basic 200 ideal hours, only 136 remain, and that’s the amount that should be considered when planning the team’s work. Every User Story has to be estimated in ideal hours. Then, we sum subsequent User Stories up to reach 136 hours.

 

 

Story points versus hours

 

Ideal hours photo

 

What approach would be best for your project? Which one to choose?

The “Story points” technique has a lot of pros:

  • It develops cooperation skills in the team, so the project has to be complexly estimated, in contrast to ideal hours, where everyone’s work is estimated individually.
  • Estimates in story points don’t get old. Estimates in “Ideal hours” estimates are subject to change, depending on the developer’s experience. “Story points” estimation determines the complexity of the project with all its aspects in mind, so they do not change.
  • Estimates in “Story points” are faster and more accurate. It is much easier to compare two values and assign numbers from the Fibonacci sequence to them than to estimate precisely in hours how long it will take to create a given functionality.
  • Estimating in “Story Points” is less stressful. If a developer estimates that it will take four hours for the functionality to be delivered, and he spends almost eight hours on it, he may stress unnecessarily.

 

So the “Story points” technique is mostly recommended for every project, especially for not experienced ones.

 

The phenomenon of estimation inflation

 

In beginner teams, where there is a lack of experience estimating in Story points, a significant improvement in the team’s speed can be noticed in a very short time. If it happens, one of the main reasons for this can be an overestimation.

 

What is estimation inflation? Basically, increasing estimates of Product Backlog Items artificially. It means that one day a team estimates a User Story for five Story Points but after some time, e.g. during the Backlog Refinement, the same team changes the number of Story Points to eight.

 

Why does it happen?

Often, Management or Stakeholders put a lot of pressure on the team to improve their productivity. In effect, the team can increase estimation to raise the team’s speed artificially.

Unfortunately for the project, when the situation requires making a decision if a User Story should be divided into five or eight Story Points, the team will choose the second option, only because it is a safer solution for them. Such a practice has several serious consequences. The main ones can be:

  • The next User Story can be estimated in comparison to the previous one, artificially raised.
  • Based on that, the Backlog can rise to an enormous size.

 

Why is it important to estimate the project properly? 

 

Every business has a budget and wants to know the costs before they’re willing to begin a project. A project estimate is your prediction of how much time and money is needed to complete a given project. An incorrect estimation can blow the project’s budget and extend the timelines, frustrating you, your client, your team, and any subcontractors.

And we want to avoid this, right?

 

Related posts: