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.

USE relative estimation on requirements

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

USE relative estimation on requirements

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 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.

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.

http://www.mountaingoatsoftware.com/blog/how-can-we-get-the-best-estimates-of-story-size

http://www.mountaingoatsoftware.com/agile/planning-poker/


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

Leadership & Management