Architectural manifesto: Adopting agile development, Part 7

Methods for estimating work effort in agile development

In this latest installment of the series, learn about estimating work effort in an agile environment. Due to the nature of software development, estimating work effort is usually difficult and often inexact. In this article, explore some useful methods that can help you estimate work effort for your agile projects.


Mikko Kontio, Partner, Dazid

Mikko Kontio has a background in software development and consulting. Formerly a director with Softera, a software development company focusing on business portals and telecom-billing solutions, Mikko is currently a partner at Dazid.

04 November 2008


This series has explored the benefits of agile processes and the requirements placed on the organizations that use them. You've learned how organizations adapt to agile development, about the different types of stakeholders, and how to apply user stories. You've walked through a case study and have seen how user stories, discussion, and prioritization can lead to quickly developed beta versions. And you have reviewed how customer incentives, behavior, and the pricing models of a project each have an effect on the current and future success of a development project.

This article explores how to estimate work efforts in agile development. Learn about work effort estimation in general, and why people do it. Then dive into the world of agile estimation and find out what types of estimates are made throughout the development process. This article also touches on a recent theme in discussion forums about the insanity of estimates and how much time it would save not to estimate at all.

Estimating work effort

People try to estimate work effort for three main reasons:

  • To know what can be done in a certain time frame
  • To calculate how much something is going to cost
  • To predict which and how many resources (developers, testers, and so on) are needed to build something

It's logical that businesses about to invest in building software need to be able to plan releases and budget for development costs, so they know what they can afford.

The product owners (the business unit or other group of people who dictate the upcoming features of the product) are interested in work effort estimations to know what features they can get into the next release. The product owners might have a set release date, and they'll want to start marketing campaigns to support the release. Some business units prefer to work the other way, with a set of features but not a fixed release date. They might have a goal, but not a set date, in mind.

If you forget all the processes (such as IBM® RUP® or agile), and think of work effort estimation as just a simplified workflow, it is quite simple:

  1. Divide the features (or requirements) into reasonably sized blocks that are small enough to be understood.
  2. Give each block a number that indicates its size compared to other blocks, or that directly represents work hours.
  3. Compare the blocks with something you've done before, get the work effort of that block size, and replace all the size numbers accordingly.

It's not very complex, but there are several steps where you can choose from many different ways of doing the estimation, and you need to have something to compare by. And, of course, remember that not all developers are the same. Some are gurus with 10 or more years of experience, and others might have only a year of experience in software development. There's a huge difference between the two.

Estimating work effort is not an exact science. The main goal is to use just enough time and energy to get an estimate that's good enough to work with.

Ways to estimate

There are three basic ways to estimate the work effort for developing software:

Expert opinion
Based on the idea that an expert will know from experience, or intuition, what it takes to build something, this method works much better with nonagile processes. In agile development, the team members should make the estimate because the team rarely consists only of experts.

If you need to get an estimate quickly, using an expert is a good method. The expert developer will read the user story, ask a few questions, and give an estimate based on experience. There is proof that this kind of estimation is quite accurate.

With this method, you split a large story into two or more smaller stories that are easier to estimate. For example, if most of the stories are under 10 days, then making an estimate of something that would take 80 days would not be very accurate. Splitting one big story into smaller stories makes it easier to estimate, and also easier to handle.
This method entails comparing the new user story, or feature, to something you've already estimated. If the story is twice the size, then the estimate should be twice as big. Another option is to compare the story to something you've already built. The purpose is not to compare all stories against one estimated story, but rather to compare it to a set of estimated (or implemented) stories.

Effort estimation in an agile way

This section touches on concepts and methods of agile estimation, including the effort-accuracy relationship, planning poker, velocity, and ideal days.

Effort-accuracy relationship

It's important to understand that, because effort estimation is not an exact science, there's a certain effort-accuracy relationship (some call it a "curve") that indicates when it is not worth doing more work because the accuracy will not improve.

Assume you have to estimate the work effort of four user stories. Consider the difference between a wild guess made without effort and an accuracy that can be somewhere between a bull's eye and a complete miss, as opposed to a short meeting with the team. The meeting would improve the accuracy of the estimates a lot, though the estimates would still not be the best they could be. Ask yourself how accurate the estimates have to be. Then compare the short meeting with the team to a half-day workshop with the team. The half-day workshop would improve the accuracy again. Compare the half-day workshop to a two-day workshop. The accuracy gained from the two-day workshop might be better, but at what time cost? It's important to know where to draw the line in the effort-accuracy relationship.

Planning poker

In planning poker, the whole team gathers to estimate the work efforts of (typically) a new sprint. Everyone involved in the development should be there: developers, testers, database designers, and so on. It's good to keep the size of the poker team under 10 people. If your team is larger, consider splitting the team into two groups. The product owner must also participate in poker but shouldn't do estimates if he or she is not also building the software.

Sometimes planning poker can also help determine the size of product backlog items or features. In this case, the estimates are looser. The purpose is to offer information that helps the product owner prioritize the product backlog.

To help ensure that your planning poker efforts are efficient and successful, you can try to:

  • Bring something good to eat, such as cookies. Sugar gives energy, the goodies make the team members feel good, and planning poker becomes a much-anticipated meeting.
  • Not allow developers to have laptops at the meeting. Instead, read the user stories or feature descriptions from a single computer or big screen. The laptops tend to distract the developers; they'll always find something else interesting to browse or tinker with.

Before the poker begins, all team members are given a deck of cards. The cards could contain numbers like 1, 2, 4, 8, and 16; some people prefer to use t-shirt sizes like XS, S, M, L, and XL. The cards should be prepared beforehand, and the numbers, letters, or t-shirt sizes should be big enough to see from across the table.

To start planning poker, either the product owner or another moderator reads the description of the user story. Any team member can ask questions about the user story. After the questions are answered, each team member selects a card that represents the size of the user story. Then everyone turns the cards at the same time. It is common for the estimates to differ quite a bit.

The lowest and highest estimators explain how they came to their estimates. They might have thought about the feature a bit differently than other team members, and they might have come up with challenges that others haven't thought about. After the explanations, the team can discuss whether the low or high estimates bring in new information or if they just weren't that accurate. The low and high estimates are not considered wrong, nor are the estimators to be considered poor estimators. This is an important point, because otherwise the whole estimation meeting won't be viewed as open, and team members will start to avoid the meeting. The low and high estimations are just different opinions that might reveal new angles to an issue.

Size and velocity

The numbers used in planning poker can, of course, be hours or days, but they can also simply be numbers that represent sizes. The numbers are called story points. A user story that has two story points might take, for example, one day to implement for a certain team.

If the team implemented 20 story points during the last iteration, they will probably implement around 20 story points in the next iteration. The team's velocity is 20 story points per iteration. Of course, if the length of the iteration is longer, the velocity is bigger. Over time the team's velocity should improve as they learn new techniques and as they become a tighter unit.

Ideal days

If you ask a developer how long it will take to implement a feature, the developer might say "five days." The developer may have actually meant, "Five days if this is the only thing I will do, but since I'll also have to do tons of other things it will probably take 10 days." The five days is called an ideal days estimate. It is important not to mix up ideal days and reality. Some teams use ideal days to estimate user stories, and then they convert the ideal days to real time with a certain factor. This factor can be determined by experience and practice.

Or, don't estimate at all

There's an alternative theory to not do the effort estimation at all. The rationale for this theory is that, since the estimation is at best only partly right, why use time and energy to do it at all? Why not use that time to develop working software? Yes, there are situations and clients where you just have to estimate work effort. But there are also situations, businesses, and applications for which that time could be used developing new software.

The trick, or guideline, to not estimating at all is to make the iterations shorter and the features smaller, then just pick the features for the next iteration that the team thinks it can deliver. This mode of thinking works well with pull-based software development and lean development.


In this column we explored how to estimate work effort in agile processes. You learned about three basic ways to estimate, as well as how to do planning poker, and the effort-accuracy relationship. The numbers used in the estimation process are not one-size-fits-all. We also explored the idea of not estimating work effort at all. In some cases, the time used for estimations could be used instead to develop new features.



Get products and technologies

  • Download IBM product evaluation versions and get your hands on application development tools and middleware products from IBM® DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.


  • Read what everyone is talking about in developerWorks blogs and get involved in the developerWorks community.
  • Check out Scott Ambler's blog - Strategies for Scaling Agile Software Development.
  • Participate in the IT architecture forum to exchange tips and techniques and to share other related information about the broad topic of IT architecture.


developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password




All information submitted is secure.

Choose your display name



Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)



All information submitted is secure.

Dig deeper into Rational software on developerWorks

ArticleTitle=Architectural manifesto: Adopting agile development, Part 7