UNIT-2

Agile estimation techniques,

Customers And Users, Time
 What is Estimation in Agile?
• Effort to complete a prioritized task in the product backlog. We measure it for the time it would
take to complete that task. As a result, you can plan sprints more accurately.

Why run Agile Estimations?

Agile estimates are essential for:

• Making teams accountable for deliverables,

• Inducing discipline across the Agile team,

• Predicting the approximate time, it will take to finish a project,

• Enabling better sprint management,

• Improving team productivity.

 Agile estimation techniques
• T-Shirt Sizing
• Sprint Poker
• Three-Point Method
• Affinity Estimation
• Relative Mass Evaluation
• Dot voting
• Maximum allowable size (MAS)
• Big, Uncertain, Small.
T-Shirt Sizing
 T-Shirt Sizing Procedure
This agile estimation technique promotes quick, collaborative estimation discussions during backlog
grooming or sprint planning. It offers simplicity, speed, and flexibility, allowing teams to prioritize tasks
efficiently.
T-shirt sizing includes team members with varying expertise levels.

How T-shirt sizing works

• Step 1: Determine the meaning of each size (e.g., XS = 1 day, S = 3 days, M = 5 days, etc.)
• Step 2: Have each team member silently choose the size that best represents the effort involved
• Step 3: Discuss the chosen sizes and adjust individual sizing, if needed, to reach a consensus

Here, all the user stories are organized according to different t-shirt sizes. Bigger user stories get bigger
sizes assigned to them. The size of one story is determined by analyzing the previous story sizes and
comparing them all.
Sprint Poker
Exhibit 2. Playing Planning Poker
Exhibit 1. Planning Poker Cards
 Sprint Poker
1. The product owner or customer reads an agile user story or describes a feature to the
estimators.
2. Each estimator is holding a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8,
13, 20, 40 and 100.
3. The estimators discuss the feature, asking questions of the product owner as needed.
When the feature has been fully discussed, each estimator privately selects one card to
represent his or her estimate. All cards are then revealed at the same time.
4. If all estimators selected the same value, that becomes the estimate. If not, the
estimators discuss their estimates. The high and low estimators should especially share
their reasons. After further discussion, each estimator reselects an estimate card, and
all cards are again revealed at the same time.
5. The poker planning process is repeated until consensus is achieved or until the
estimators decide that agile estimating and planning of a particular item needs to be
deferred until additional information can be acquired.
 Three-Point Method
Three-point Estimation looks at three values −
• the most optimistic estimate (O),
• a most likely estimate (M), and
• a pessimistic estimate (least likely estimate (L)).
 Three-Point Method
• There are times when a project ends up taking more time than what was estimated before beginning. The three-
point method is the best way to eliminate this issue. The three-point method takes three different approaches to
estimation.

• This method loops in the best-case scenario, the worst-case scenario, and the most likely scenario. The average
of all these estimates is then calculated to give us the final estimate. In this method, the team needs to measure
time/effort based on the following parameters:
• Optimistic Value (O): How much time/effort will it take if everything is on track?

• Pessimist Value (P): How much time/effort will it take if things fall apart or there are impediments on the way?

• Most Likely Value (M): What is the most likely and practical estimate to complete the task?

How three-point estimation works

• Step 1: Explain the concept of estimating: M (most likely), O (optimistic), and P (pessimistic) effort

• Step 2: Get each team member to estimate the M, O, and P effort for the task

• Step 3: Calculate the average using either of the following methods

 Affinity Estimation
Three steps of Affinity Estimation are:

1. Silent Relative Sizing

2. Editing the Wall
3. Placing items in correct bucket
 Affinity Estimation Procedure
Step 1: Silent Relative Sizing
• First a horizontal scale is chosen.
One end of the scale is marked with
“Smaller” and the other end is
marked with “Larger”
• The product owner provides the user
stories to the team.
• Each participant estimates their
story solely without any discussion
with other participants and after
estimation, places it at the correct
location on the scale, anywhere
between “Smaller” and “Larger”.
 Affinity Estimation Procedure
Step 2: Editing the Wall
• Once each story is placed on the
scale team members edit the
relative sizes on the wall. For this
team discussed about the story with
each other about its design,
implementation or any challenges.
Team gets all the doubts clarified
from Product Owner as well.
• Based on the understanding made
during discussion, team re-arranges
its story on the scale if required.
Affinity Estimation Procedure

Step 3: Placing items in correct bucket

• The scale “Smaller” to “Larger” is
divided and marked appropriately
with the markers of XS, S, M, L, and
XL if we use t-shirt sizing technique
or with 0, 1, 2, 3, 5, 8, 13, and so on,
if we use Fibonacci series of planning
poker estimating technique.
• Team member now places their
stories, which were on scale
“Smaller” to “Larger”, to appropriate
bucket of the converted scale.
 Relative Mass Evaluation
1. Write up a card for each story.
2. Then set up a large table so the stories can be
moved around easily relative to each other.
3. Pick any story to start, then get the team to
estimate whether they think that it is relatively
large, medium, or small.
4. If it’s a large story, place it at one end of the
table. If it’s a small story, it goes at the other
end of the table. A medium story goes in the
middle. Now select the next story and ask the
team to estimate if it’s more or less effort than
the story that you just put down. Position the
story card on the table relative to the previous
card, and go to the next card.
 Dot Voting
1. All user stories are put on a wall, virtual or real by the Product
Owner.
2. Every team member is given 4-5 votes; these can be small round
sticky notes.
3. Every team member is asked to give their votes on the stories
they think are bigger.
4. Team member puts/pastes the round red sticky notes on the
stories they think are big in size.
5. Every team member performs this process until their all 4-5
votes are exhausted/used. At the end of this process, the story
with higher votes is termed as biggest and that with low number
of votes are smallest.
6. Product owner then orders the story from higher votes to lower
votes.
7. One person can vote more than once for one story.
8. Same technique is used to decide priority as well. More votes
means higher priority item.
 Maximum allowable size (MAS)
1. Set your estimation scale. In this case, it might be worth using a
scale according to the number of hours something will take, so
you have a concrete idea of the maximum amount of time you
want your team to spend on a given piece of work. This will
make your filtration more actionable.
2. As a general rule, user stories probably shouldn’t take more than
16 hours of work, otherwise they can become unwieldy. So you
might want to take 16 hours as your maximum allowable size. If
you don’t need the same level of precision, use the good old t-
shirt sizes to guide you.
3. Now the task is to go through all the stories in your backlog and
filter out the ones the team think are higher than 16 hours by
voting on them.
4. You can then take those items and discuss how to break them
down so they fit below the maximum allowable size.
 Big, Uncertain, Small
The ‘Big/Uncertain/Small’ agile estimation method is similar to the bucket system. It
involves placing the estimated items in one of the three categories. Teams discuss the items
and then a ‘divide-and-conquer’ technique used to estimate the rest of the items. The items
left are distributed among team members and can be quickly estimated in parallel.
 Customer and User

• Who is a customer?
• Who is a User?
• Can customer be a user?
• Can a user be a customer?
• Who can be a user?
• Who can be a customer?
Customer Vs User
 Customer Role
• The customer describes the project vision, the project main stories,
and the guidelines according to which development priorities will
be set.

• The architects present their vision about the product architecture,

including the existing architecture and anticipated changes.

• The project manager presents his or her view of the development

process and the working environment as well as his or her personal
expectations.

• Other stake holders present their expectations from the

development process.
Business days
 Business Day
The main Business Day activities are:
• presentation of the accomplishments of the ending iteration;
• measures’ review;
• customer feedback;
• reflective session;
• planning of the next iteration.
 Presentation of the System
• The features that are presented belong to specific customer stories
of the ending iteration.
• We demonstrate progress by delivering tested, integrated code that
implements a story. A story should be understandable to customers
and developers, testable, valuable to the customer,
 Customer feedback
• The customer feedback is a short, informal verbal summary of the
iteration, given by the customer. This direct feedback usually focuses
on the product rather than on the process. It is important to include
the customer’s message in the iteration summary to signal the
customer’s importance in the development process. It also helps in
focusing people on the product as an end goal,
 The reflective session
• The reflective session is intended to discuss a specific issue in the
development process, and to change the process if needed.
 Planning the next iteration
• Time is an important resource and should be managed wisely.
• The smaller a development task is, the more accurate its development
time estimation is. Thus, product delivery on time and of high quality is
better ensured.
• An ordered professional work environment is required by professional
practitioners; chaos frustrates professionals especially because the
resulting products are of low quality and their professionalism is
doubted.
• Fairness and a cooperative work environment are valued by
professional developers; an open and transparent work distribution, in
which all parties are involved, increases practitioners’ security, trust,
and cooperation.
 Customer Collaboration
• To focuses on the common language required in order to maintain
ongoing communication with the customers.
• First, be aware of metaphors.
• Second, encourage developers to provide multiple metaphors:
( NOTE: A metaphor is a figure of speech that describes an object or
action in a way that isn’t literally true, but helps explain an idea or
make a comparison.)
 The User
• The Human Computer Interaction (HCI) field emerged in the
early 1960s.
• Norman (2006) suggests abandoning the traditional HCI
approach of ‘‘study first, design second’’ and to try the ‘‘design,
then study’’ approach.
• The integration of the user in the development environment is
accomplished by the User Centered Design (UCD) approach,
which is a set of design techniques
• that emphasizes user needs during the design of the user
interface. This is achieved by managing user evaluation with
validated user evaluation techniques (Vredenburg et al. 2002).
 UCD
There are two main types of evaluation:
1. expert-based evaluation and
2. user-based evaluation.

• Expert-based evaluation, a designer or an HCI expert assesses a design of

user interfaces based on known cognitive principles or empirical results.

• The user based evaluation is based on user participation, i.e., evaluation

that involves the people who are going to use the system. User-based
evaluation techniques include experimental methods, observational
methods, questionnaires, interviews, and
Cognitive principles
 Customers and Users in Learning
Environments
• Elicit Communication
• Use Metaphors or ‘‘Other World’’ Concepts
• Case Studies of Metaphor Use
• Case Study 3.2. Identification of Short Sequence Repetitions in a
DNA Sequence
• Case Study 3.3. Personal Information Organizer
TIME
 Introduction
• Time is addressed differently by different people and cultures;
• for example, in western culture, time is mainly associated with financial
profit, i.e., ‘‘Time is money.’’
• Time plays a special role in software engineering: the project schedule
should be met, the product should be delivered on time, teammates should
complete their tasks on time, and so on.
List of Time-Related Problems in Software Projects
1. Bottlenecks:

In software development occur when one or more functions in the process

await the output of another function in the process, with teammates
having nothing to work on in the meantime.

Eg. when developers wait for artifacts from system analysts, like the
specification of a specific module.
 List of Time-Related Problems
2. Project planning and schedule.

Two main problems are associated with schedules, which are, in fact,
closely connected. The first is the mere construction of a feasible
project schedule. The second problem is to meet the schedule that
has been set.
 List of Time-Related Problems
3. Time estimation. There are different ways to support time estimation
• (Boehm 1981, Boehm et al. 2000, Kemerer 1987, SEI 2001). With
respect to the estimation of the development time of a specific
module/class/task, it is well known that the greater the
module/class/task is, the more difficult it is to estimate its
development time.
• Tomayko and Hazzan (2004) present evidence that the smaller the
estimated unit is, the more accurate is its time estimation.
 List of Time-Related Problems
4.Time pressure

• Time pressure is the result of the previous problems. It happens

usually toward the end of the development process, when
teammates cannot meet the project schedule, either because of
poor time estimations or bottlenecks.

• Time pressure usually leads to the skipping of different testing

activities, which in turn leads to a decrease in software quality.
 List of Time-Related Problems
5. Late delivery

▪ Late deliveries occur as a result of inappropriate project planning,

usually due to poor estimations.

▪ Data indicate that the percentage of software projects that fail to

accomplish on-time delivery is quite high.

▪ See, for example, the data presented by the Standish Group

Report (Standish 1994).
 Tightness of Software Development Methods
• Project plan dimension: number of releases and feedback milestones, level of
emphasis placed on planning, number of days for which specific planning is
made (the smaller the number of days, the tighter the software development
method).
• Procedures and standards dimension: level of detail that describes the
software development method.
• Responsibility and accountability dimension: level of role performance, level of
personal accountability, frequency at which team members are required to
report on their progress.
• Time estimation dimension: importance given to time estimation, resolution
level of time estimation (hours, days, months)|the smaller the time units, the
higher the resolution, and the higher the value of this dimension.
• Individual need satisfaction dimension: mutual dependency of team members,
level of planning that inspires the message ‘‘Invest now for the future.’’
 Sustainable Pace
• Tightness is one time-related characteristic of agile software
development. Sustainable pace is another one.
• Sustainable pace means that the development process is carried
out in a reasonable number of hours, which are well planned
and enable the team to be productive and to produce quality
products
Case Study 4.2. An Iteration Timetable
of an Agile Team
Time Management of Agile Projects

1. Time Measurements
Time Management of Agile Projects
Time Measurements
2. Prioritizing Development Tasks
Case Study 4.4. First Things First
First Things First
Time in Learning Environments

1. The Planning Activity

The Planning Activity
 2.Teaching and Learning Principles
• Teaching and Learning Principle 3: Explain
While Doing
• Teaching and Learning Principle 8: Manage Time
 3. Students’ Reflections on Time-Related Issues
• ‘‘MUCH more time should be dedicated to the planning of the structure
of the program, both interfaces and implementation, before anyone starts
writing any code.’’
• ‘‘Things usually take more time than expected, especially because of
integration and misconceptions |this must be taken into account when
estimating times.’’
• ‘‘As for time evaluation, we met our estimations almost exactly, and in
some cases even finished tasks sooner than we had expected.’’
• ‘‘In iterations 2 and 3 the times were better defined, because of the
experience we had gained.’’
 4. The Academic Coach’s Perspective
The planning session gives the academic coach an excellent
viewpoint on the students’ work with respect to the project’s
planning, the design of its parts, and the development
management. During the planning activity, the academic coach
becomes extensively familiar with the project details and with
each student’s part in the development.