MODULE 4:
PLANNING
AGILE TECHNOLOGIES.
Your best quote that reflects
your approach… “It’s one small
step for man, one giant leap for
mankind.”
- NEIL ARMSTRONG
1. Vision
Meaning & Importance
A product vision is the ultimate goal or purpose of the system.
It provides a strategic direction that aligns stakeholders, developers, and customers.
Without a clear vision, teams may deliver functionality, but not necessarily the right functionality.
Characteristics of a Good Vision
Inspiring – motivates the team by focusing on “why” the project matters.
Concise – ideally 1–2 sentences that everyone can remember.
Customer-focused – expresses value to end users rather than technical details.
Stable – unlike requirements, the vision does not change frequently.
Example
“Build a platform that enables rural students to access
affordable digital education.”
This vision tells developers that every feature must enhance
accessibility and affordability, not just add technology for
its own sake.
MCA DEPARTMENT
Vision
“To be a centre of excellence in Computer Applications
with quality education and research, responsive to the
needs of the industry and society.”
2. Release Planning
Purpose
Decides which features (stories) will be delivered in upcoming releases and when.
Ensures that releases provide incremental business value and opportunities for
customer feedback.
Key Ideas
Release = Major milestone (often 2–6 months).
Incremental value delivery: each release must deliver working software.
Adaptability: release plans are not fixed contracts; they evolve as requirements
change.
Steps in Release Planning
1. Collect user stories.
2. Estimate each story’s size (story points/ideal days).
3. Prioritize stories by business value and risk.
4. Allocate stories into releases based on velocity and
deadlines.
Example
Release 1 (3 months):
Iteration 1: Login, registration.
Iteration 2: Profile, password reset.
Iteration 3: Course catalog, enrollment.
Release 2 (next 3 months):
Iteration 4: Payment gateway.
Iteration 5: Course delivery system.
Iteration 6: Feedback and grading.
3. The Planning Game
(XP Practice)
Introduced by Kent Beck in XP.
A collaborative planning exercise where customers and developers
decide scope and schedule.
Roles
Customer: defines business priorities.
Developer: provides technical estimates.
How It Works
1. Customer proposes user stories (business value).
2. Developers estimate cost (effort, complexity).
3. Together they negotiate what will go into the iteration/release.
Strengths
1. Prevents one-sided decision-making.
2. Builds trust by making trade-offs transparent.
3. Keeps plans realistic because they are grounded in both value and
feasibility.
Example
Customer: “Payment feature is critical for launch.”
Developer: “It is 13 points, so it might require trade-
offs. Do you want to drop ‘Profile Customization’ (5
points)?”
Outcome: Payment is included, customization is
deferred.
4. Risk Management
Importance
Software projects are uncertain by nature. Agile emphasizes early
identification and handling of risks instead of ignoring them until it’s too
late.
Risk Categories:
Technical Risk – Can the system handle load? Will new technology work?
Business Risk – Will customers use the product? Is ROI achievable?
Project Risk – Can deadlines be met? Are key skills available?
Agile Risk Strategies
1. Deliver early & often – detect risks quickly.
2. Address high-risk stories first – fail fast and learn.
3. Build spikes/prototypes – test feasibility before
investing heavily.
4. Regular retrospectives – identify new risks
continuously.
EXAMPLE RISK MATRIX
Risk Probability Impact Mitigation
New database may Conduct spike in
High Severe
not scale Iteration 1
Customer changes Use frequent
High High
requirements demos & feedback
Team member Pair programming,
Medium Moderate
attrition cross-training
5. Iteration Planning
Purpose
Iteration = short cycle (1–4 weeks) delivering working
software.
Iteration planning answers: What stories can we complete
this iteration?
Process
1. Select highest-priority stories from release backlog.
2. Break stories into smaller tasks (6–16 hours each).
3. Developers estimate tasks and volunteer for them.
4. Team commits to a realistic workload (based on
past velocity).
Example
Story: As a student, I want to search courses.
Tasks:
Design UI (8 hrs).
Implement backend search (12 hrs).
Write automated tests (6 hrs).
Integration and deployment (6 hrs).
6. Slack
Slack = planned buffer time for unexpected events or innovation.
Without slack, teams over-commit and fail when interruptions occur.
Slack means keeping some extra free time in your team’s plan.
This time acts like a safety cushion so the team doesn’t get stuck
when unexpected work comes up.
Without slack, the team becomes overloaded and misses deadlines.
Why Do We Need Slack?
1. Unexpected Bug Fixes → Sometimes a critical bug
appears that must be fixed immediately.
2. Improving Code (Refactoring) → Developers may
need time to clean and improve old code.
3. Research or Experimenting (Spikes) → Team may
need to try out a new tool, library, or approach.
Best Practice
Reserve 10–20% of iteration capacity as slack.
EXAMPLE:
Imagine a team can usually finish 20 story points of work in one iteration
(2 weeks).
If they plan all 20 points, and then a surprise bug appears, they cannot
finish everything.
Instead, they plan only 16–18 points and leave 2–4 points free (this is
slack).
If nothing unexpected happens, they can use slack for learning, code
improvement, or small innovations.
7. Stories
Definition: User Stories = lightweight, customer-
centric requirements.
A User Story is a short, simple description of a
feature told from the perspective of the person who will
use it (customer, user, or stakeholder).
It focuses on what the user wants and why, not on
how the developers will build it.
In Agile, stories are usually written on index cards or
sticky notes to keep them short and encourage
conversations.
Format
“As a [role], I want [feature], so that [benefit].”
As a [role] → Who is the user?
I want [feature] → What do they need?
So that [benefit] → Why do they need it? (business value)
Example
As a teacher, I want to upload assignments so that students can access
them online.
Properties (INVEST)
Independent – deliverable separately.
Negotiable – details evolve via conversations.
Valuable – meaningful to customer.
Estimable – can be estimated.
Small – fits in one iteration.
Testable – has acceptance criteria.
Properties of Good Stories
(INVEST)
1. Independent
◦ Each story should be deliverable on its own.
◦ Example: “Upload assignments” can be delivered without waiting for
“grading assignments.”
2. Negotiable
◦ Stories are not contracts. They are reminders to discuss details with the
customer.
◦ Example: Teacher may later clarify the file size limits or formats.
3. Valuable
◦ Must provide clear value to the end-user or customer.
◦ Example: Students save time; teachers don’t need to print assignments.
4. Estimable
•Team should be able to estimate the effort.
•Example: Developers can estimate how long it takes to build
file upload functionality.
5. Small
•Should fit within a single iteration (1–2 weeks).
•Example: “Upload assignments” is small. “Create complete
learning management system” is too big → must be split into
smaller stories.
6. Testable
•Each story must have clear acceptance criteria (how to
check if it’s done).
•Example:
•Teacher can upload PDF/DOC files.
•Students can view/download uploaded files.
8. Estimating
In Agile, estimation helps teams predict the effort
and complexity of work items (user stories, tasks).
Estimates are not exact numbers; they are best
guesses to support:
[Link] – Business can compare high-value
vs. high-effort stories.
[Link] Forecasting – Helps decide when features
or releases will be delivered.
Common Estimation Techniques
1. Story Points
Relative measure of complexity, not hours or days.
Teams assign points to stories based on:
◦ Effort
◦ Complexity
◦ Uncertainty
Often use Fibonacci series (1, 2, 3, 5, 8, 13, …) → because
differences between numbers grow, which helps reflect
uncertainty in larger stories.
Example:
Login feature → 2 points (small, simple).
Payment integration → 8 points (complex).
Recommendation engine → 13 points (very
complex, uncertain).
2. Planning Poker
A group estimation game.
Each team member holds cards with numbers (1, 2, 3, 5, 8, etc.).
The Product Owner describes the story.
Everyone picks a card secretly and reveals at the same time.
If estimates differ widely (e.g., 3 vs. 13), the team discusses
reasons and votes again until they agree.
Encourages collaboration and avoids one person dominating.
3. Ideal Days
Team estimates how long the work would take if
there were no interruptions (meetings, emails,
waiting).
Example: “This story would take 2 ideal days.”
Useful, but often less reliable because real work
always has interruptions.
Velocity
Velocity = average number of story points a team
completes in one iteration.
Calculated after each iteration.
Used for forecasting: How many iterations are needed
to finish the backlog.
Example
Iteration 1 → Team finishes 18 points.
Iteration 2 → Team finishes 20 points.
Average Velocity ≈ 19 points per iteration.
Now, assume the product backlog has 95 points
worth of work.
DEVELOPING:
1. INCREMENTAL REQUIREMENTS
What it means ?
In Agile/XP, we don’t write one giant requirement document at the start.
Instead, requirements grow step by step while we are also coding,
designing, and testing.
The requirements are “living” – they change as we learn more from
customers and working software.
Customers are involved all the time (ideally in the same room) so we can
ask, clarify, and update quickly.
How it works in the Agile/XP lifecycle
1. Vision → Release Planning
◦ First decide the release date.
◦ Then let the scope be flexible: choose Minimum Marketable Features (MMFs),
break them into stories, estimate, and prioritize.
◦ Detail only what’s needed soon (“last responsible moment”).
2. The Planning Game
◦ Developers estimate cost.
◦ Customers decide value and priority.
◦ Together, they create the best plan.
3. User Stories = reminders for conversations
◦ Short, simple cards (“As a customer, I can reset my password…”).
◦ Not full specifications – details come later during discussion.
4. Just-in-time detail via Customer Tests
o Before coding, customer + tester write acceptance tests.
o These tests confirm what “done” means.
5. Vertical slicing
o Deliver thin slices that go end-to-end (UI + logic + DB).
o Example: “request password reset” is one slice, “consume
token” another.
o Aim for 4–10 small stories per iteration.
6. Continuous feedback
o At the end of each iteration, demo to customers.
o Use their feedback to re-prioritize for the next iteration.
Why it’s better ?
Responds to change: because we don’t freeze
details too early.
Encourages collaboration: customer + developers
decide together.
Reduces waste: no giant unused documents, only
stories and tests that matter.
2. Customer Tests (Acceptance Tests)
What they are ?
Customer Tests = also called Acceptance Tests.
They describe what the system should do from a
business/user point of view.
Written mainly by the customer (with help from
testers/developers).
They turn customer requirements into executable
checks.
Why they matter ?
They define “done” for a story.
When automated, they run continuously → making
sure new code doesn’t break old features.
They give customers confidence because they can
see their requirements being met.
Developers benefit too: it’s easier to know when a
feature is complete.
How they work in practice ?
Write story:
“As a user, I can reset my password so I can access my account
again.”
Turn into Customer Test:
◦ Given a registered user
◦ When they request a password reset
◦ Then they receive an email with a reset link
Automate the test:
◦ Run it automatically whenever the system changes.
◦ If the test passes → the requirement is satisfied.
3. Test-Driven Development
(TDD)
What it is ?
TDD = a coding style where you write
tests before the code.
It follows the Red → Green → Refactor
cycle.
The Cycle (Red → Green → Refactor)
1. Red – Write a small test for new functionality.
It fails (because the code doesn’t exist yet).
2. Green – Write the minimum code to make
the test pass.
3. Refactor – Clean up the code (remove
duplication, improve design) while keeping all
tests passing.
Why it’s powerful ?
1. Ensures correctness (code always verified by tests).
2. Produces simple, clean design (since you only
write what’s needed).
3. Provides a safety net – if you break something later,
tests fail immediately.
4. Supports evolutionary design – architecture grows
naturally, guided by tests.
4. Refactoring
What it means ?
Refactoring = changing the inside of the code (structure,
naming, design) without changing what it does.
Think of it like tidying up your room – you rearrange
things so it’s easier to use, but nothing is lost.
The goal: keep code readable, flexible, and easy to
change.
Why it’s important
Code naturally becomes messy as features are added.
If we never clean it, we build up technical debt (like
credit card debt — the longer you wait, the worse it
gets).
Refactoring ensures:
1. Code is easier to understand.
2. Bugs are easier to spot and fix.
3. New features are easier to add.
How we do it safely ?
Refactoring is always supported by unit tests
and customer tests.
Tests act as a safety net:
◦ If tests pass after refactoring → behavior is unchanged.
◦ If something breaks, a test will fail immediately.
5) Simple Design
What it is (XP’s definition)
“Simple design” means build the simplest thing that works
today—no speculative hooks—while following XP’s rules:
1) Runs all tests ·
2) No duplication (“Once and Only Once”) ·
3) Expresses intent (communicative) ·
4) Minimal elements (fewest classes/methods consistent with
clarity).
Why it works ?
Avoids wrong abstractions: it’s usually easier
to add than to undo a bad “future-proof”
design.
YAGNI: if a design element doesn’t support
current stories, don’t add it. Remove dead
code to shrink cognitive load.
“Once and Only Once” often reveals elegant
designs when you keep eliminating
duplication.
Problems:
Duplication: price × quantity is calculated twice.
Poor intent: no clear method names → reader must
trace the loop.
Mixed responsibilities: calculating & printing in the
same function.
Improvements:
•No duplication: subtotal() reused in both places.
•Express intent: names say exactly what they do.
•Minimal methods: only what’s needed, but clear.
•Readable: someone scanning code instantly
understands.
6) Incremental Design &
Architecture
What it is
Architecture evolves as you deliver stories. You start
specific, then generalize only when new needs
appear. This scales the TDD rhythm (small step →
prove → improve) from methods to classes, packages—
even architecture.
How it works in XP ?
1. TDD = proves small parts are correct.
2. Refactoring = keeps code clean and adaptable.
3. Stories/iterations = add real pressure → system
grows naturally.
4. Team standards (shared coding style, working
together) = prevent drift.
Example
•Release 1: Build “search by name” with
a simple filter.
•Release 2: Need “search by tag” →
extract a SearchSpec class.
•Release 3: Add “search by date range” →
extend SearchSpec + add DB index.
No big upfront “search framework.” Just
evolve as needed.
7) Spike Solutions
What they are
A spike is a time-boxed experiment—write the
quickest code or script that answers a technical
question (library behavior? API latency? framework
fit?). It’s intentionally rough and often throwaway; the
point is real data over speculation.
Types of spikes
Technical spikes: test a tool/technology.
◦ Example: “What happens if we add 1 to
Integer.MAX_VALUE?”
Design spikes: try a possible design.
◦ Example: prototype database persistence
quickly.
Real-world spike
Question: “Does TensorFlow Lite run smoothly on a low-end
Android device for real-time object detection?”
Spike: Write a 2-hour demo app → test on target phone.
Result: FPS too low → team decides to try a lighter model
(MobileNet).
Spikes = “Try small, fail fast, learn quickly.”
They save weeks of wrong investment by providing real
data over speculation.
Keep vs. discard
Keep the learning (notes, wiki,
maybe the sample code in /spikes
folder).
Discard the messy spike code → don’t
put it in production.
Spikes reduce risk and uncertainty
before making a big decision.
8) Performance Optimization
Optimize only when there’s a measured need.
Premature tweaks add complexity and can even slow
things down. Treat performance like any other value:
write performance stories with clear goals, then
measure, change, and re-measure.
Define goals → Measure → Improve → Measure again.
Performance story example
Goal: Checkout should respond in ≤ 1 sec (95% of the time).
Acceptable: ≤ 2 sec, Best: ≤ 1 sec.
Process (Perf Flywheel)
[Link] (end-to-end, realistic load).
[Link] (find the slowest part).
[Link] small (fix only that bottleneck).
[Link] (measure again).
5. Stop when criteria met.
Example
Current checkout P95 = 2.4s.
Target = ≤ 1.0s.
Profile: slow shipping API.
Solution: add caching + async prefetch.
New P95 = 0.92s → ✅ Done.
9) Exploratory Testing
What it is ?
A human, investigation-driven testing style where
designing the next test is guided by what you just
learned.
It complements automation and is best when stories are
“done-done.”
Goal: discover surprises, weak spots, and real-world
edge cases—not to replace automated checks.
Four core tools
1. Charters: short missions that focus the session (e.g.,
“Explore Coupon + Bulk Discount interaction; watch for perf
regressions”). Sessions are typically 1–2 hours.
2. Observation: humans notice oddities automation misses
(weird cursor state, suspicious URL param). Follow the
thread.
3. Note-taking/Recording: keep steps so bugs are
reproducible; list branches to explore later.
4. Heuristics: boundary values, stress, interruptions, error
recovery—maintain your team’s heuristic catalog.
Example charters
Malicious curiosity: change URLs to check for
security holes.
Network misery: test with very slow internet.
Interrupted flows: close app during checkout → can it
recover?
Persona sweep: try the same flow as guest, user,
admin.
Why it’s valuable
1. Finds integration issues automation misses.
2. Reveals usability flaws (human
perspective).
3. Provides feedback on quality beyond
correctness.
THANK YOU