1

Getting Agile Teams Started With Estimation

NK Shrivastava and Phillip George, RefineM LLC
Many agile teams, especially new teams, struggle with estimation. Many people are reluctant to produce
estimates, and if they are too high or low, problems can occur. In this article, we describe challenges in
estimating, especially for agile projects, and present three techniques to help teams progressively
develop their estimating skill and precision.
Estimates can be a contentious topic among project teams, even in agile. Many developers and project
team members are reluctant to provide estimates because they dont have enough information to come
up with much more than a guess, but that guess ends up becoming a commitment. When work ends up
taking longer than estimated, the team has to work overtime to make up the difference, resulting in
lower morale and rushed work.
In addition, estimating too high or too low carries risk. Estimating too high threatens to invoke
Parkinsons Law, which states that work expands to take the time available to complete it2. For example,
if work that actually takes six months is estimated at one year, the team will likely spend between six
months and one year on the project because that time is available to them. On the other hand,
estimating too low means that the team will have to rush to finish the work, leading to possible rework.
How can teams develop the art and science of estimating? One way is to estimate only when the
estimate is needed. Agile fits within this mindset since work in later iterations is estimated closer to the
time it starts. Just because agile fits this mindset does not mean that agile estimating is easy. In this
article, we present tools, techniques, and tips to help agile teams get started with estimates and
overcome the common problems with estimating agile projects.

1 Photo Credit: Helio Madeiros, Flickr. Creative Commons Licensed.

2 Wikipedia (2015). Parkinsons Law. Accessed 2015 13 October from https://en.wikipedia.org/wiki/Parkinson's_law

www.refineM.com Contact@RefineM.com 405 N. Jefferson Ave, Springfield, MO 65806 417.763.6762

Challenges in Agile Project Estimating

While traditional project teams estimate activities defined from a work breakdown structure (WBS),
agile teams estimate tasks from user stories. User stories are tokens representing a feature or piece of
functionality to be included in the product. They usually take the form of a declaration: for example, As
a project manager, I want to be able to see upcoming tasks for the next month so I can plan status
reports. They are useful conversation pieces for the team to discuss, produce estimates, and define
testing criteria.
Even with user stories, agile teams can sometimes struggle in developing clear requirements. In agile,
user stories need to reflect requirements clearly so teams can effectively estimate the relative size of
the story. Teams often struggle with estimating user stories in two ways. First, they leave them too large
and do not break them down effectively. When user stories are too large, the estimates are more likely
to be inaccurate and teams are more likely to struggle with completing these stories in an iteration.
Many teams are also not comfortable with progressively elaborating requirements, which will happen in
agile. Rather than seeing user stories as full specification documents, teams need to see them as tokens
for conversation and development over time.
In addition, variety in productivity also poses a challenge to effective estimation. This issue manifests in
agile when teams base story points on complexity, not effort, a mindset that takes time to change. Mike
Cohn illustrates this mindset using the concept of two people running a five-mile trail. The first person, a
skilled runner, can complete the trail run in thirty minutes. The second runner is a novice and needs
sixty minutes. Regardless of how long each person takes to run the trail, it is the same distance3.
Finally, scaling technical solutions can pose a problem with effective estimation, even in agile. Because
agile is localized to teams of 5-9 people, when an organization needs to scale agile to realize benefits
across the enterprise, they may often struggle. Expanding the team can be disruptive, so the
coordination effort happens between teams using a method like the scrum of scrums, where teams
send representatives to a higher-level meeting to collaborate on larger items.
Despite these challenges, effective estimation can happen within agile. In addition, some challenges that
traditional projects face are not problems within agile. Fluidity in scope is welcomed rather than
discouraged, and because agile encourages experimentation, variety in development tools can be
accounted for. Now that weve demonstrated some of the difficulties in producing effective project
estimates in an agile way, we look at some ways that a team can get started in agile estimating and
improve their skills, from the abstract method of using t-shirt sizing to the more precise methods of
story points and hours.

3 Cohn, Mike (2014, 9 September). The main benefit of story points. Accessed 2015 13 October from
https://www.mountaingoatsoftware.com/blog/the-main-benefit-of-story-points

www.refineM.com Contact@RefineM.com 405 N. Jefferson Ave, Springfield, MO 65806 417.763.6762

Tools and Techniques to Get Started with Estimation

Agile teams can look to three progressively elaborating techniques to develop and refine estimates:
1. T-shirt sizes. Teams new to agile may benefit from using t-shirt sizes as their first
introduction to relative sizing. Instead of assigning a numerical estimate to a story, team
members will indicate whether it is small, medium, large, or extra-large (S, M, L, XL). The
team may also use other shirt sizes like XXL or XS (Extra-Small). Instead of measuring
velocity in story points, teams measure it by the number and size of shirts delivered; for
example, three smalls, two mediums, and a large.
T-shirt sizing is a useful estimation tool for new teams so that they can get used to relative
sizing. It also works well when not much is known about a story, feature, or epic. While an
abstract system like t-shirt sizing is good as an introduction, as teams get better at
estimating, they should shift to story points for better precision and ability to communicate
velocity and iteration or release size.
2. Story points. Story points are a numerical representation of relative sizing that are used to
get more precise estimates than t-shirt sizing. Using story points, if one story is rated as 4
points and another is rated as 2, then the first story is twice as big as the second.
Teams getting started with using story points will likely benefit from planning poker, a team
exercise designed to reach consensus on estimates. Planning poker should involve as many
people from the team as possible, including developers, testers, business analysts, and
other key stakeholders. The teams ScrumMaster and product owner help facilitate planning
poker sessions.
Each team has a set of cards. Various decks are available online, including from Mountain
Goat Software and other outlets. The cards are usually in modified Fibonacci sequence, as
seen in Figure 1.

Figure 1. A set of Planning Poker cards that would be used by an estimator.

www.refineM.com Contact@RefineM.com 405 N. Jefferson Ave, Springfield, MO 65806 417.763.6762

The product owner starts by reading a user story. It may be the highest-priority story or a
small story to set a baseline for other stories to size relatively. Estimators ask questions to
get more details about the story, and when they are ready, they play a card face-down and
all cards are revealed at the same time. If the team has a consensus, then the product
owner records the estimate and moves on to the next story. If there is not a consensus, the
ScrumMaster and product owner lead discussions to account for variances. These
discussions can result in changes to estimates, which continue until consensus is achieved.
Planning poker is a fun exercise that provides teams equal footing to discuss estimates and
can also be used to unearth project risks.
3. Task estimates in hours. While story points and relative sizing work well at the user story
level, eventually teams need to break stories into tasks and assign hours. This breakdown
helps teams fit their work into iterations and better communicate progress with
stakeholders. Teams create the task level estimation in hours during iteration planning so
they have a high level of accuracy when they start the work. Hours are typically measured in
ideal time, or the amount of time a task will take with no interruptions. Because it is not
realistic to expect zero interruptions, teams commonly use a focus factor, like 0.6 or 0.8, to
adjust estimates. This adjustment accounts for time spent in meetings, operational work, or
absences.
To effectively estimate in hours at the task level, teams need to develop skill in three areas.
First, they need to be able to break down user stories. How small a story needs to be
depends on many different factors, including the teams comfort level. As a general rule, if a
story is so large that it cannot fit in one iteration, then it needs to be broken down. Teams
can break down user stories in many ways, including finding tasks from multiple steps in a
story, looking for themes where stories are related, and looking at teams specialized skills
and breaking down tasks to determine the right fit for team members.
Second, teams need a clear definition of done. In agile, the definition of done is the set
of criteria the team agrees on to consider a task or story complete. Teams need to establish
this criteria for each story so they can estimate based on everything that needs to finish to
satisfy the criteria. If teams dont set a definition of done, their estimates will be off
because they do not have a clear signal that a story is finished. If the definition of done is
missing important tasks like testing and acceptance, then the estimates will be too low. For
these reasons, effective estimates depend on a clear and complete definition of done.
Finally, teams need a mechanism for assessing their own skills and developing targets for
improvement. In agile, they have this mechanism in the form of retrospectives. Teams
should make sure that they hold retrospectives at the end of each iteration. Whereas the
iteration review helps the team and the customer discuss the product and identify areas of
improvement, the retrospective is more of a meta-meeting where the team looks at its own
processes and identifies areas of improvement. Because estimating is tied so closely to
other parts of the process, like iteration and release planning and velocity, looking at the
estimation process with a critical eye is crucial for teams to develop their skill at estimating.

www.refineM.com Contact@RefineM.com 405 N. Jefferson Ave, Springfield, MO 65806 417.763.6762

Conclusion
Many of the inherent challenges of estimating projects are still present in agile. Developing effective
estimates is difficult when the requirements are not clear and information is not known. When team
members vary in productivity, their estimates can vary. If technical solutions need to scale, team
members can struggle with scaling the estimate to match. In addition, estimates carry risks if they are
too low or too high, and many team members are reluctant to even make estimates for this reason.
Teams can overcome these challenges and produce estimates that help them succeed on their projects,
even in agile. They can achieve this goal by following a progressively elaborating process for estimating,
starting from the abstract t-shirt size, going to the more precise story points from planning poker, and
then estimating specific tasks in hours. By strengthening their skill at breaking down user stories and
clarifying their definition of done, teams can develop estimates that precisely communicate the size of
the project and the effort required to deliver it. Finally, through effective use of retrospectives, teams
can assess their progress with these skills and brainstorm ways to improve.
Many of the struggles with estimating in an agile way are natural for new agile teams or teams that are
not effective at estimating. Overcoming these struggles will help them turn their estimating skills into an
advantage, putting them on the path to becoming mature agile teams.
References
1. Cohn, Mike (2014, 9 September). The main benefit of story points. Accessed 2015 13
October from https://www.mountaingoatsoftware.com/blog/the-main-benefit-of-storypoints
2. Wikipedia (2015). Parkinsons Law. Accessed 2015 13 October from
https://en.wikipedia.org/wiki/Parkinson's_law

www.refineM.com Contact@RefineM.com 405 N. Jefferson Ave, Springfield, MO 65806 417.763.6762