UNIT II

An Agile Approach: An Agile Approach To Projects, An Agile Approach to

Planning Estimating Size: Estimating Size with Story points, Story Points Are
Relative, Velocity, Estimating in ideal days, Ideal Time and Software Development,
Ideal Days As A Measure of Size, One Estimate, not Many.
The four principle Agile statements come from the Agile
Manifesto, and their introduction highlights why Agile teams
prioritize them the way they do

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

Individuals and Interactions over Processes and Tools
Agile teams believe that skilled, motivated people collaborating
effectively will outperform rigid processes and advanced tools if
those tools replace human problem-solving. The focus is on
leveraging each person’s unique strengths and fostering strong
communication rather than trying to make everyone interchangeable
through strict processes.

Working Software over Comprehensive Documentation

The priority is to have a functioning, tested product at the end
of every iteration. This ensures that feedback can be gathered
early and often, making it easier to adjust direction based on
Customer Collaboration over Contract Negotiation
Agile emphasizes building a shared goal between the development
team and the customer. While contracts are still necessary, they
should support cooperation rather than create an “us vs. them”
mindset. Collaboration ensures that all parties adapt together as
the project evolves.

Responding to Change over Following a Plan

Agile acknowledges that initial plans will change as new insights
emerge. The ability to adapt to changes whether in user needs,
market conditions, or technical realities ensures the project
delivers the highest value possible instead of sticking to an
An Agile Approach To Projects

Agile team works in the following ways

• Work as one team

• Work in short iterations

• Deliver something each iteration

• Focus on business priorities

• Inspect and adapt

1. Work as One Team
All members share the same vision and success criteria.
No isolated roles : analysts, designers, coders, and testers
collaborate directly.
Key roles:
Product Owner: Sets vision, prioritizes features.
Customer: Funds or purchases the software.
Developers: Includes programmers, testers, UX, DB engineers,
etc.
Project Manager: Leads, facilitates, removes obstacles.
Culture: “We’re all in this together.”
2. Short Iterations
• Small, fixed timeframes: 1–4 weeks (timeboxed).
• All activities : requirements, design, coding, testing happen
together in the iteration.
• Ensures fast feedback and quick adjustments.

3. Deliver Something Each Iteration

• End of each iteration = potentially shippable product.
• Features are fully coded, tested, and ready for release (even
if not released yet).
• Multiple iterations make up a release (typically 2–6 months).
• Encourages incremental progress and reduces risk.
4. Focus on Business Priorities
• Build the most valuable features first to maximize ROI.
• Product Owner prioritizes features in the backlog.
• Use User Stories for simple, clear requirements:
• “As a <user type>, I want <capability> so that <business
value>.”
• Minimize technical dependencies so priorities are flexible.
5. Inspect and Adapt
• Plans are living documents, updated every iteration.
• Feedback from users and team experience shapes future work.
• Adjust priorities when:
• Some features are valued more than expected.
• Others are less important than planned.
An Agile Approach to planning

1. Definition of Agile Planning

• What Agile planning means compared to traditional planning.
2. Core Idea
• Planning is not rigid but adaptive and iterative
3. Key Principles
• Focus on value delivery
• Emphasis on flexibility
• Ability to respond to change quickly
4. Why It Matters
• Ensures projects stay aligned with business goals
• Helps teams manage uncertainty and change effectively
• Improves customer satisfaction through collaboration
[Link] Objective
• Deliver working solutions in small increments
• Generate knowledge + capabilities at each step
What Agile Planning Is

• What is Agile Planning? (Concept)

• Agile planning = iterative and adaptive approach to project
planning.
• Breaks down work into short cycles (iterations).
• Focuses on small, manageable cycles (iterations) instead of
one big plan.
• Promotes continuous feedback and improvement from users and
stakeholders

Why It’s Called ‘Agile’

• “Agile” = ability to move quickly and adapt to change.
• Plans are not rigid; they evolve as the project progresses.
Why It Is Different from Traditional Planning

Traditional Planning

• Fixed upfront plan (waterfall approach).

• Predicts scope, cost, and schedule at the start.

• Limited ability to handle changes once work begins.

Agile Planning vs Traditional

• Agile = adaptive race (progress with time limit).

• Traditional = fixed finish line race (predictable path).

• Agile accepts that requirements may change, while traditional

assumes they won’t.
Focus on Flexibility, Adaptability, and Value Delivery

Flexibility & Adaptability

• Plans adjust based on new knowledge.

• Responds to changing customer needs and priorities.

• Encourages continuous learning within the team.

Value Delivery

• Deliver highest business value first.

• Every iteration ends with working product increments.

• Success measured by customer satisfaction, not just “finished

tasks.”
Multiple levels of planning
Planning Across Multiple Horizons
• Agile teams engage in planning at three distinct levels to
ensure adaptability.
• Release planning focuses on the scope, schedule, and resources
for a three to six-month period.
• Iteration planning occurs at the start of each iteration,
detailing tasks for the upcoming work cycle.
• Daily planning involves short-term coordination during daily
standup meetings.
Conditions of Satisfaction in Planning
• Understanding the product owner’s conditions of satisfaction is
crucial for project success.
• Conditions of satisfaction include scope, schedule, budget, and
quality.
• The team collaborates with the product owner to explore and
meet these conditions.
• Iterative planning allows for adjustments to conditions when
necessary to achieve project goals.
Conditions of satisfaction
Estimating Size

Estimating size involves determining the overall amount of work

or effort required for a task or project, without directly
considering the time it will take to complete. In agile
projects, size is often estimated using relative measures like
story points or ideal days.
Key Concepts of Estimating Size:
Separation of Size and Duration: Agile teams first estimate the
size of a task (e.g., the amount of work or complexity) and then
convert it into duration based on factors like team velocity or
available resources.
Relative Estimation: Size is often estimated in relative terms
rather than exact measurements. For example:
Story Points: A unit of measure expressing the relative size of
a user story or feature. A story with 2 points is twice as
large as a story with 1 point.
Ideal Days: The number of uninterrupted, focused workdays
required to complete a task.
Factors in Estimation: Size estimates consider elements
like:
Effort required,
Complexity of the task,
Risks involved,
Dependencies.
In the example provided, the size of the task is estimated as 300 cubic feet
of dirt. This is a measure of the total volume of dirt to be moved. However,
size alone does not indicate how long the task will take. To estimate the
duration, the size must be converted into time based on the tools and
processes available.
Here’s how the duration of 5 hours is calculated:
Tool Capacity: The wheelbarrow has a capacity of 6 cubic feet.
Number of Trips: To move 300 cubic feet of dirt, it will take 300 ÷ 6 = 50
trips.
Time per Trip: Each trip involves:
3 minutes to load the wheelbarrow,
2 minutes to walk to the other side of the yard and dump the dirt,
1 minute to walk back with the empty wheelbarrow.
Total time per trip = 6 minutes.
Benefits of Estimating Size:
• Provides a clear understanding of the scope of work.
• Enables teams to plan and prioritize tasks effectively.
• Serves as the foundation for calculating duration and creating
schedules.
Estimating Size with Story points

Estimating Size with Story Points is an agile approach that

separates the estimation of a project's size from its duration.
Instead of directly estimating how long a task will take, teams
first assess its size using a relative, unitless measure called
story points. This method allows for a more flexible and self-
correcting planning process
Imagine a software team working on an e-commerce website. They have
three user stories:
User Story A: “As a user, I want to log in with email and password so
that I can access my account.”
User Story B: “As a user, I want to make payments using credit cards so
that I can complete my purchase.”
User Story C: “As a user, I want to see personalized product
recommendations so that I can discover products easily.”

Step 1: Estimation in Story Points

The team estimates complexity, effort, and risks for each:
Story A (Login feature) → Small, straightforward → 3 points
Story B (Payment integration) → More work, dependencies (bank APIs,
Step 2: Sprint Planning with Velocity
Suppose the team’s velocity = 20 story points per sprint (based on past
performance).
In one sprint, they could finish:
Story A (3) + Story B (8) + Story C (13) = 24 points Too much
Story A (3) + Story B (8) + another 9-point story = 20 points Fits
well

Step 3: Benefits
Relative Estimation → Instead of debating “Is login 6 hours or 10
hours?”, the team compares complexity.
Predictability → By knowing velocity, the team forecasts how many
sprints are needed.
Focus on value, not time → Encourages teams to collaborate and think
about business value.
Think of story points like difficulty levels in exams:
• 3-point = short-answer question
• 8-point = case study question
• 13-point = long research essay
Story points are relative
Story points being relative means that the specific numerical
value assigned to a story is less important than its value in
comparison to other stories. It's a way of expressing the overall
size of a piece of work, such as a user story or feature.
Here's a brief explanation:
• Comparative Sizing: When estimating with story points, the aim
is to indicate that one story is larger or smaller than another
. For example, a story given two points should represent twice
Labrador Retriever is chosen as a medium dog → given 5 dog points.
Great Dane is about twice as tall as a Labrador → 10 dog points.
Saint Bernard is slightly smaller than a Great Dane → 9 dog points.
Dachshund is much smaller → 1 dog point.
Terrier and Poodle are variable breeds, so the author just guessed 3 dog points on
average.

The exact numbers don’t matter. What matters is the relationship:

Great Dane ≈ 2 Labradors
Dachshund ≈ 1/5 Labrador
Saint Bernard ≈ 9/5 Labrador
Labrador Terrier
Retriever paddle
Great Dane

Saint
Dachshund German
Bernard
Shepherd

Bull dog
Velocity?
Velocity is the measure of how much work a team can complete in a single iteration
(usually a sprint in Agile).
• Work is measured in story points (or sometimes ideal days).
• Velocity is simply the sum of the story points of all completed stories in one
iteration.
Suppose your team is working in 2-week sprints:
In Sprint 1, they complete:
Story A: 5 points
Story B: 3 points
Story C: 2 points
Total = 10 story points
In Sprint 2, they complete:
Story D: 8 points
Story E: 5 points
Total = 13 story points
Why Velocity is Important
Predictability
If a project has 100 story points total, and the team’s average velocity is 10
points/sprint, the project will take 10 sprints (about 20 weeks for 2-week sprints).
Planning
Velocity helps teams and product owners decide how many stories can fit into the
next sprint.
Self-Correcting Nature
If the team underestimates or overestimates story sizes, velocity naturally balances
it out.
Example: If every story turns out harder than expected, the team completes fewer per
sprint → velocity reflects the real pace.
Velocity = Story points completed per iteration.

It allows teams to forecast project timelines and plan realistically, based on their
actual performance rather than guesses
Velocity Corrects Estimation Errors
Velocity corrects estimation errors by providing a self-correcting mechanism
within a points-based estimation approach. This means that as an agile team
progresses through a project, their actual rate of progress (velocity)
becomes apparent and automatically adjusts duration forecasts, even if the
initial size estimates of the work remain constant.
Here's how it works:
• Initial Planning Assumption: When a project begins, teams might estimate
the total size of the work in story points (e.g., 200 points) and make an
initial assumption about their velocity (e.g., 25 points per iteration) to
derive a project duration (e.g., 8 iterations
Estimating in ideal days
Difference Between Ideal Time and Elapsed Time

Ideal Time: The actual amount of focused time a task would take
if you did only that task without distractions.
Example: Writing a report might take 1 ideal day if
uninterrupted.

Elapsed Time: The total real-world time needed to finish the

task, including meetings, emails, support calls, or task-
switching. That same report may take 3 elapsed days to complete.
Football Example

A game of American football officially has four quarters, each

lasting 15 minutes.
So, by rules, the game’s ideal time = 60 minutes.

But in real life, when you watch or attend a football game, it

Estimating in ideal days involves predicting the amount of uninterrupted,
focused time required to complete a user story, assuming no distractions, all
resources are available, and the story is the sole focus. Ideal days are a
measure of size, similar to story points, and do not account for external
interruptions or organizational overhead. This method simplifies estimation
by focusing solely on the effort required, separating it from elapsed time.
Ideal days can be converted into project duration using velocity, just like
story points. It is recommended to assign a single aggregate estimate to each
user story rather than breaking it down by roles to maintain team cohesion
and reduce administrative complexity.
Ideal Time and Software Development

Applying Ideal Time in Projects

In software, the gap exists because of:

• Emails, meetings, phone calls

• Bug fixing and support work
• Task switching and multitasking
• Training, reviews, interviews, etc.

When estimating in ideal days:

• Assume the story is the only work being done

• All resources are available when needed
• There are no interruptions
Refers to the time required to complete a task with no distractions or
interruptions
Assumes the developer works only on the task with all resources
available
Elapsed time (real clock time) is longer due to:

Meetings
• Emails and phone calls
• Bug fixes and support issues
• Multitasking and task switching

Example:
• Estimated task = 5 ideal days
• Real completion = ~2 weeks elapsed time

Why Ideal Time is useful:

• Easier to estimate than elapsed time
• Focuses only on pure effort
• Separates work size from schedule duration
• Makes planning and forecasting more straightforward
Ideal Days As A Measure of Size
Ideal days are a way to estimate the size of a task by focusing only on
the time it would take to complete it without interruptions or delays.
For example, if creating a screen takes one ideal day, it means one
full day of focused work without distractions like meetings or emails.
This method ignores external factors like company overhead or
multitasking, making it easier to estimate the effort required. Once
the size is estimated in ideal days, it can be converted into actual
project duration using the team's velocity, just like with story
points.
What are Ideal Days?
An ideal day means one full day of focused work with no interruptions.
Example: If making a screen takes 1 ideal day, it means 1 day of pure coding without
meetings, emails, or other tasks.

Why use Ideal Days?

It ignores distractions (like company overhead, multitasking, or support work).
Makes it simpler to estimate effort because you only think about the actual work.

How is it used?
First, the team estimates tasks in ideal days (e.g., 5 ideal days).
Then, using the team’s velocity (how much work they finish in real life), these ideal
days are converted into a real calendar schedule.
Works the same way as story points → size first, then duration.

Ideal days = pure work time → helps estimate effort clearly, and velocity converts it
One Estimate, not Many
Instead of saying:

• Programmer needs 2 days

• Tester needs 1 day
• Designer needs 1 day
• Total = 4 days
We just say:

The whole story will take 4 days (one single

estimate).
Why do this?

• Keeps things simple – no need to track each role separately.

• Builds a team spirit – everyone feels responsible for the story, not just “their
part.”

• Saves time – avoids extra admin work of calculating and updating multiple role-based
estimates.

When separate estimates are needed

Only in special cases, like when building different versions of the same product (Mac,
Windows, mobile) where specific skills are required.

But in most projects, a single unified estimate is better.