Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
AGILE ESTIMATING
V1.0
AGILE ESTIMATING
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.
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 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 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).
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.
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.
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.
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.
Effort – the whole work needed, i.e. the mental exertion to conceptualise
and write the code, unit test, documents, etc.
B
A
1 St or y Point 8 St or y Point s
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”.
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
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.
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.
REMEMBER
Relative estimation is a conversation that evolves over time.
Estimation is valuable when it helps you make a significant 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.
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.
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.
1. Before Sizing
The room had been booked and a time-box
was allocated.
2.During Sizing
I explained the rules to the participants and
informed about the timebox.
3. After sizing
Everyone got an estimated backlog and
there is now a shared understanding of
the items.
Estimating
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.
1. Before Sizing
The room had been booked and a timebox
was allocated.
3. After sizing
Everyone got an estimated backlog and
there is now a shared understanding of
the items.