AWB - 05 - Agile Estimating

161 Agile White Book – AXA Emerging Markets EMEA-LATAM
Chapter 5
AGILE ESTIMATING
V1.0

Contents
WHAT I WILL LEARN IN THIS CHAPTER?.................................................................................................................................................................... 164
UNDERSTAND THE PROBLEM ............................................................................................................................................................................ 165
USE RELATIVE ESTIMATION ON REQUIREMENTS ......................................................................................................................................................... 166
BENEFITS OF RELATIVE ESTIMATION ........................................................................................................................................................................ 169
CALCULATE THE AVERAGE VELOCITY..................................................................................................................................................................... 170
LEARN & IMPROVE.............................................................................................................................................................173
USE T-SHIRT SIZES...............................................................................................................................................................175
USE PLANNING POKER .........................................................................................................................................................176
THE EXPECTED OUTCOME ................................................................................................................................................................................ 178
TAKE AWAY.................................................................................................................................................................................................. 179
CHECKLIST 5.1.................................................................................................................................................................................................. 180
CHECKLIST 5.2.................................................................................................................................................................................................. 183

Agile estimating
An Agile Estimation allows you to know relative
sizes of requirements and makes it easier to
prioritize them in a Product Backlog. It provides a
way to balance the effort needed to achieve an
estimate with its reliability.

What I will learn in this chapter?
AGILE ESTIMATING
KNOW HOW TO ESTIMATE
- Relative Estimation
- T-shirt sizes
- Planning Poker
- Etc.
VELOCITY
I know the benefits of using relative estimation.
I know how to use Planning Poker & T-shirt sizes.
I know how to calculate velocity.
CAN CREATE A
BACKLOG
UNDERSTAND
WHY WE USE
ESTIMATIONS

UNDERSTAND the problem
For some business domains, creating detailed estimates that can withstand scrutiny from
“scientific” teams may be necessary. This is generally done by balancing the current knowledge
with some contingency for the “known unknowns”.
Detailed estimates can be seen as a factor that distracts from delivering Business Value.
Additionally, the accuracy of the estimates decreases when objectives are not in the near future.
Another factor that can help when estimating is the more team members who are involved in
estimation of a particular task. Furthermore, different groups of people could experience a unit of
time (i.e. hours) in different ways as a result of many factors, such as:
 Availability.
 Multitasking.
 Understanding of the problem.
 Tools and experience on the field.

USE relative estimation on requirements
Agile uses relative estimation which offers many advantages compared to standard estimation.
Agile widely utilizes estimation in units other than time, that help to avoid some of the pitfalls
associated with estimating in general: seeking unwarranted precision and confusing
estimates for commitments.
Ilan Goldstein in his book Scrum Shortcuts without Cutting Corners: Agile Tactics, tools and tips
indicates, relative estimation applies the principle that comparing is much quicker and more
accurate than deconstructing (detailing). It means that instead of trying to break down a
requirement into tasks (and estimating it), people compare the relative effort of completing a
requirement to the relative effort of a previously estimated requirement or one used as a
reference.
People in general are good at estimating sizes but not so good at estimating time. For
example, you could instantly know which country is bigger if we say Luxemburg, Spain or USA. You
can also start making some assumptions with just some basic knowledge about relativity. Let’s
look at an example…
You look at the buildings above and compare their sizes.
You climb the big one and realise you reached your full-day capacity when placing a foot on the
roof. Now you got some conclusions as a result of that:
 The right hand size building is more or less twice the size of the left one.
 Your capacity allows you to climb the smaller one easily.
Let´s place a relative number (or building-points) to each one: 10 to the small building, 20 to the
big one as it is twice the size (a one-and-a-half size building would be 15).

You have learnt so far how to:
 Use relative estimation.
 Produce an Estimate.
 Use value Points.
 Know your Velocity.
 Know your Capacity.
 Use Analogy.
 Know when an estimate is more
accurate.
You can then start comparing buildings and easily realise that as an example:
 You can climb no more than 20 building-points a day.
 You can have an average velocity of 600 building-points in a month.
 You can also do some maths to get some more/indirect results.
You could also use Analogy here, for example, if you do not have any previous experience at
climbing buildings but you walked all the way up to the top of the Eiffel Tower, you could easily
triangulate that information and know how many building-points you would be able to do in one
day.
Obviously, the estimation will be less accurate if the elements to compare have a huge
difference in size (a gigantic building) or are too far away.
As we will see later, we call the point in Agile Story Points as we are not climbing buildings but
analysing User Stories (requirements).

I am giving User Story/Requirement D
3 Story Points, because it feels like its
implementation will take a little bit more
effort than User Story/Requirement A,
which I have already rated at 1 story point,
and somewhat less effort than User
Story/Requirement C, which I rated as 5
points
You could also use t-shirt sizes (i.e. XL, L, M, S) instead of points in cases where you don’t need
that much precision or the important part is just the order of magnitude between items. If you
are able to climb an M sized-building in 1 day, you would certainly be able to do the same with
an S but probably struggle with an XL in one day.
Finally, you can use a technique called Triangulation which is the process of establishing the size
of a User Story/Requirement relative to two others, with the purpose of increasing the reliability
of the estimate.
Have in mind that when using Triangulation, you constantly learn from the estimation process.
In order to do that, you can imagine/represent visual connections between all user stories so
that any user story is compared, directly or indirectly, to every other element. Triangulation is
also an effective means for a Team to verify that they aren't gradually altering the meaning
of a story point.

Benefits of relative estimation
Relative estimation makes easy to "triangulate" estimates between different requirements, i.e.
checking whether a group of requirements is consistent to their size. That is also helpful when you
want to know if a requirement should be in another group.
As Agile estimates are produced by people generally located in the same place and sharing
common goals, it allows them using great synergies in a positive way, to create knowledge and
experiences that helps achieve the best solution in the shortest time. It also produces a more
reliable estimate, as done by considering the knowledge and experience of several people.
Finally, it creates a great sharing and learning environment as everyone understands what the
requirement means before sizing it.

CALCULATE the average velocity
Average Velocity allows you to know the approximate number of Story Points that a Team will
be able to deliver at the end of a Sprint. The Product Owner would eventually need this
information in order to have a rough idea of how many User Stories can fit into a release.
I follow these steps to successfully calculate velocity:
 Take the last 3 or 4 Sprints, calculate the average number of Story Points delivered.
 If the team structure changes (different, more or less people), I ask the team if they
feel confident about keeping the same velocity.
 If technology or any other tool changes, I ask team members if they are
comfortable about sticking to that average velocity
 I remember and consider public holidays, possible holidays and any other events.
 Ensure that the team stays focused. Whenever possible, I try to get rid of all
unnecessary meetings or any other things that do not add any value to the project.
If there is no possibility to reduce them, I try to consolidate many into one period of
time.
 If velocity varies a lot from Sprint to Sprint, I analyse root causes and reasons.

Remember it is very important you differentiate between the
number of Story Points that were completed by the Team (fact)
and accepted by the Product Owner as "done", and the average
Velocity (forecast).
There is an initial scenario where no velocity is available for the Team, in that case, apply one
of the following points:
 Ask the team if they had worked with a similar product before and see if they believe
that the velocity value can be re-used.
 Ask the team how many stories they think they would be able to finish in a sprint
and obtain that rough number (only with experienced/mature Agile Teams)
 Check on how many story points they were able to produce in Sprint 0 (initial Sprint
where all infrastructure, technical aspects and documents are prepared) and use that
value.

In Agile, Story Points are only
achieved when a User Story is fully
finished; no points are obtained for
partial work.
Remember that Story points are basically derived from 3 parameters:
Complexity – how difficult it is to find/recreate the scenario.
Effort – the whole work needed, i.e. the mental exertion to conceptualise
and write the code, unit test, documents, etc.
Risk – uncertainties about technologies or domain knowledge that the team
has.
A
B
1 Story Point 8 Story Points

LEARN & IMPROVE
Velocity and good estimates are like wine, they get better with time. Changes inside the team,
technology/tools/location and the way people work can have a serious impact on it. Have in mind
that it belongs to a specific team and it is always an average and never a fact!
 Focus on Retrospectives – teams should always discuss in a retrospective their
current velocity.
 Analyse causes of rework - all agile practices have a certain amount of rework in the
form of changed requirements, immature or poorly defined requirements, technical
debt, defects, performance considerations and other sources such as unavailability of
the Product Owner. Always consider labelling stories (or tasks) based on the source of
the rework and then evaluate different measures that might reduce rework and affect
estimates.
 Business insights give smarter decisions – Know more about the business as it
gives you better working capabilities (stories) and helps improve prioritisation and
coding. Make sure the team clearly understands the project goals and objectives
when there is a change.
 Make things simple and clear – Do you have any doubts about the technology used
or technical challenges with legacy code? Do you consider that the features can be more
specific or sliced in smaller chunks (to avoid complexity)? Discuss with the Product
Owner and Team why it is happening and assure you always challenge the current
solution in order to get a better result.

The following pyramid gives you an idea of the different areas to deal with inside the teams in
order to improve Agility.
Many of these areas can be analysed and targeted during a retrospective.

USE T-SHIRT SIZES
In Agile, estimation can be done during different stages, by different people and using diverse
techniques. In the initial phases of a project and while creating a High-Level Product Backlog,
the Product Owner with the help of Stakeholders, Key Users and Key Experts (Development
Team), estimate Goals/Epics/Features using T-shirt sizes. This is in this way as the main
objective is to gain some relative idea of magnitude (know how big it is; accuracy is not the
main goal in here). The dynamic is very simple and allows people to know the relative size of an
element.
Open the checklist “Estimating using T-shirt sizes” to see how to
estimate in the initial phases of a project using T-shirt sizes.

USE PLANNING POKER
Agile requirements are written as User Stories, which is a short statement of how a specific type
of user will use the software, why she needs it and her clear need (business reason): “As a loan
manager, I will be able to retrieve a client’s credit rating, so that I can determine if they qualify for
a loan”.
It states the requirements at a higher level, but leaves room for specific implementation
discussions later. The basic idea behind Story Points Estimation is to assign an abstract value to
the relative complexity of a User Story (requirement). Someone from the Development Team
will pick a simple story that everyone understands and they decide to assign it 3,5 or 8 Story
Points. That is your base Story. After that, the team can estimate comparing the User Story to the
base Story that has been defined. Is it a lot bigger/smaller/similar in size?
Teams typically assign points using special poker cards with a modified version of the Fibonacci
sequence (1, 2, 3, 5, 8, 13, …) where numbers are further apart as they get higher, to reflect the
fact that the larger the effort, the more imprecise the estimate can be.
Use the checklist “Detailed estimation using Story Points & Planning Poker”.

Don’t forget that:
 An estimate is an approximate number and not
an exact value.
 Velocity is an average and not a fixed number.
 Velocity may be affected if the structure of the
team changes.
Have in mind that in Agile you don’t design or estimate all the features until there has been a
level of prioritization and you’re sure you have chosen the ones close to be developed.
You used a phased approach to estimation, recognizing that you can be more certain as the
project progresses and you learn more about the features and its risks.
You can also calculate Velocity, which is an average number of Story Points that a Team can
achieve in a Sprint.
This technique is typically used in Sprint Planning but can be also used in other scenarios.
Remember that Agile estimating involves the entire Team during the estimation process
Some things to do when using Agile Estimation:
 Clarify the value of Agile Estimation and make sure that the value and purpose are
shared across the whole team.
 Invest in improving the collaboration mechanisms instead of trying to achieve a fix
velocity number.
 Evolve your approach as the team grows. In the early stages, it may be worth
spending just a little bit more of time and effort to understand the requirements.
 Do not attempt to compare the velocity between teams.

THE EXPECTED outcome
After reading this how-to, you and the Team should have understood:
 How to produce an estimate using T-shirt sizes, Poker cards, Analogy and
Triangulation.
 How to differentiate between relative and absolute estimation.
 That each team’s approach to estimation evolves as the project progresses.
 How to identify what the concepts of Analogy, Velocity, Story Points and Capacity
mean.

TAKE AWAY
REMEMBER
 Relative estimation is a conversation that evolves over time.
 Estimation is valuable when it helps you make a signiﬁcant decision.
 Keep the focus of the scope in terms of a Minimum Valuable Product and then analyse capacity
in Story Points.
 Everybody should understand the concept of how relative estimation works.
 Keep estimates manageable.
DEEPEN YOUR KNOWLEDGE
How can we get the best estimates of Story Size?
Planning Poker
BENEFITS
 Align all the people involved.
 Keep everyone away from seeking unwarranted precision and confusing estimates for commitments.
 Make things simple (velocity, metrics, etc.)
Prevents the need for frequent re-estimation.
Story Points alleviate fear of commitment with time.

Estimating using T-Shirt sizes
Checklist 5.1
Version 1.0
DATE: __________
Audience
Context
One of possible way to perform comparable estimation via estimation in T-shirt sizes. This
technique is more often used during the initial phases of the project.

Task Comments
1. Before Sizing

The room had been booked and a time-box
was allocated.
 Pens and sticky notes were available.

I got a deck of pre-designed cards with XXL,
XL, L, M values and I prepared a set of them
for each participant.

All the elements to be estimated were placed
on the wall or table.
2.During Sizing
 I explained the rules to the participants and
informed about the timebox.

As relevant people arrived, I asked them to
choose the element that involved the
smallest effort.

Everyone agreed that the chosen
“reference” item is an S size.
 I gave each one 4 cards with t-shirt sizes

One delegate (Scrum Master or other) took
an item and read it loudly.

People asked all the things they need to
know or were not clear until they were fully
satisfied.

Everyone chose a card expressing the size
for the item chosen and placed it facing down
on the table without sharing its value with
anyone.


All the members turned the card up at the
same time and shared the values with the
rest of the team.

If no agreement, a conversation was
established to clarify the scope of the item or
what it entailed.

The poker planning process was repeated
until consensus was achieved or until the
estimators decided that agile estimating and
planning of a particular item needed to be
deferred until additional information could be
acquired.

The User Story was placed in the designated
area for that size and the size was marked
down on the card.
3. After sizing

Everyone got an estimated backlog and
there is now a shared understanding of
the items.
Estimating

using Poker & Story Points
Checklist 5.2
Version 1.0
DATE: __________
Attendants
Context
One of the most popular estimation techniques from Agile framework is estimating Poker. The
techniques provides unbiased estimates from all people involved in estimation exercise, which
facilitates knowledge sharing within the team.

Task Comments
1. Before Sizing

The room had been booked and a timebox
was allocated.

Product Owner/Development Team/Scrum
Master were invited and a detail of the
activities was sent

Pens and sticky notes were available.

I got a deck of pre-designed Agile Poker
Cards and I had prepared a set of them for
each participant

All the User Stories to be estimated were
placed on the wall or table (or close to the
Kanban).
2. During Sizing
 I explained the rules to the participants and
informed about the timebox.

Task Comments

As relevant people arrived, I asked them to
choose the element that involved the
smallest effort.

Everyone agreed that the chosen
“reference” item is 1 Story Point.

I gave each one 4 cards with Story Points.
 The Scrum Master took a User Story and
read it loudly.

People asked all the things they need to
know or were not clear until they were fully
satisfied.

Everyone chose a card expressing the size
for the item chosen and placed it facing down
on the table without sharing its value with
anyone.

All the members turned the card up at the
same time and shared the values with the
rest of the team.

If no agreement, a conversation was
established to clarify the scope of the item or
what it entailed.

The poker planning process was repeated
until consensus was achieved or until the
estimators decided that agile estimating and
planning of a particular item needed to be
deferred until additional information could be
acquired.

The User Story was placed in the designated
area for that size and the size was marked
down on the card.

Task Comments
3. After sizing

Everyone got an estimated backlog and
there is now a shared understanding of
the items.

AWB - 05 - Agile Estimating

Recommended

Recommended

More Related Content

What's hot

What's hot (16)

Viewers also liked

Viewers also liked (6)

Similar to AWB - 05 - Agile Estimating

Similar to AWB - 05 - Agile Estimating (20)

Recently uploaded

Recently uploaded (9)

AWB - 05 - Agile Estimating