Agile Module 4
1. What is risk? Explain project specific risks in detail. (10 Marks)
Risk is the possibility of an uncertain event or condition occurring in a project that can
have a positive or negative impact on project objectives such as scope, time, cost, or
quality. In Agile and Extreme Programming (XP), managing risk is crucial because
stakeholders expect reliable and timely delivery despite uncertainties like requirement
changes, technical failures, or team disruptions.
Project-Specific Risks
Apart from generic risks (flawed release plans, requirement growth, employee turnover),
each project has unique risks depending on its domain, technology, and stakeholders. These
are identified using a risk census, typically through brainstorming sessions where the team
lists potential catastrophes, their scenarios, and root causes.
Categories of Project-Specific Risks
1. Technical Risks:
o Use of new or unproven technologies that may fail.
o Integration problems between modules or external APIs.
o Performance bottlenecks (e.g., server downtime due to high demand).
2. Resource Risks:
o Key team members leaving, falling sick, or being unavailable.
o Lack of required skill sets in the team.
o Delays due to dependency on external vendors or third parties.
3. Requirement Risks:
o Stakeholders changing priorities unexpectedly.
o Major tweaks requested late in the release.
o Misunderstood requirements leading to rework or defects.
4. Operational Risks:
o Hardware or software failures (e.g., hard drive crash, server downtime).
o Security issues such as denial-of-service attacks.
o Inadequate backup and recovery strategies.
5. Business Risks:
o Product may succeed technically but fail to satisfy key stakeholders.
o Market demand may be lower than expected.
o Project may exceed budget or miss delivery deadlines.
Managing Project-Specific Risks
• Identification: Brainstorm potential catastrophes, scenarios, and root causes.
• Assessment: Estimate probability (high, medium, low) and impact (cost, time,
quality).
• Response: Decide whether to avoid, contain (e.g., use risk multipliers), or mitigate
risks.
• Monitoring: Track transition indicators to detect risks early.
• Mitigation/Contingency:
o Mitigation activities reduce risk impact before it occurs (e.g., prepare load
balancer).
o Contingency activities are executed only if the risk occurs (e.g., purchase
additional servers).
• Risk Exposure: Calculated as Probability × Impact, helping allocate budget and
schedule padding.
Example:
If a risk is “unexpected popularity overloads servers,” mitigation might be adding horizontal
scalability and load balancer setup, while contingency could be purchasing extra servers
or bandwidth.
2. Explain the concept of stories in release planning. (10 Marks)
In Agile development, especially Extreme Programming (XP), stories are the basic units of
planning that connect customer needs with development effort. They play a central role in
release planning.
What is a Story?
• A story is a short, simple description of a feature or functionality, written from the
customer’s perspective.
• It acts as a promise for future conversation, meaning the details are discussed later
with the customer.
• Stories are small, independent pieces of work, usually taking 1–2 days to complete.
• Each story must have clear completion criteria, so customers know when it is done.
Example:
“As a warehouse manager, I want an inventory report so that I can track stock levels.”
Purpose of Stories in Release Planning
1. Planning Tool: Stories are used to create the release plan, breaking down the project
into manageable pieces.
2. Prioritization: Customers decide which stories bring the most business value,
guiding development focus.
3. Estimation: Developers estimate the effort for each story; combined with team
velocity, this predicts delivery timelines.
4. Flexibility: Stories are independent, allowing the release plan to adapt each iteration
without disrupting the whole project.
Characteristics of Effective Stories
• Customer-Centric: Stories describe value to the user, not technical tasks. Technical
work is included in the story estimate.
• Right Size: A team should complete 4–10 stories per iteration.
o Large stories are split.
o Very small stories are combined.
• Physical Story Cards: Stories are often written on index cards and displayed on
release and iteration boards, helping the team visualize priorities and track
progress.
Special Types of Stories
1. Documentation Stories: Manuals, reports, or other documentation needed.
2. Non-Functional Stories: Performance, scalability, stability, or other system qualities.
3. Bug Stories: Fixing defects not resolved immediately during development.
4. Spike Stories: Research or investigation tasks to enable accurate estimation of
technical work.
Stories are the building blocks of release planning in Agile. They ensure that the team
focuses on customer value, allows for accurate estimation and prioritization, and provides
the flexibility needed to adapt plans as project needs evolve. By using stories, Agile teams
can deliver predictable, incremental releases that satisfy stakeholder requirements.
3. Explain how incremental design works in XP. (10 Marks)
In Extreme Programming (XP), incremental design (also called evolutionary design) is a
way to build software architecture and technical infrastructure gradually, while still delivering
customer-valued functionality every iteration. XP teams are expected to deliver 4 to 10 stories
per week, and customers may change or introduce new stories at any time. This makes
traditional upfront design impractical, so incremental design provides a solution by allowing
design to evolve alongside the software.
How it works:
1. Start simple: For any new design element—a class, method, or architectural
component—create the simplest design that solves only the current problem. Avoid
over-engineering or trying to solve future problems prematurely.
2. Incremental generalization: Each time the same design element is reused for a new
problem, modify it just enough to accommodate the new scenario. This ensures the
design grows naturally based on real needs.
3. Continuous improvement: After each change, review the design and refine it.
Simplify and clarify the code to improve readability and maintainability. Over multiple
iterations, the design gradually becomes more abstract and robust, without unnecessary
complexity.
4. Supporting practices: Incremental design works closely with Test-Driven
Development (TDD), which ensures each step is tested and functional, refactoring to
continuously improve code quality, and pair programming and collective code
ownership to maintain a clean, shared design understanding across the team.
By following this approach, XP teams can deliver high-quality, customer-focused software
quickly, while keeping the design simple, flexible, and powerful. Incremental design ensures
that software evolves naturally, guided by practical needs rather than speculative future
requirements.
4. What are Spike solutions? Explain performing experiment and scheduling spikes. (10
Marks)
In Extreme Programming (XP), a spike solution (or spike) is a small, focused experiment
conducted to investigate or clarify a technical or design problem. XP values concrete data
over speculation, so whenever a team encounters uncertainty, they perform a spike rather than
guessing.
About Spike Solutions
• A spike is a technical investigation or prototype created to answer a specific question.
• Examples include:
o Testing whether a programming language throws an exception on arithmetic
overflow.
o Exploring how a framework or API behaves.
• Spike solutions are typically small, standalone, and not part of production code. They
may be discarded after use or stored separately for reference.
Performing the Experiment
• Create a small program or test to demonstrate the feature or solve the technical
question.
• Focus on practical understanding, not perfect production-ready code.
• Keep the spike simple and isolated: hardcode values, ignore user input unless
necessary.
• Use test frameworks if convenient to run and report results quickly.
• After completion, either discard the spike or store it in a separate directory for
documentation or reuse.
• For design spikes, sometimes you work with production code to test a design approach
or framework, but carefully isolate spike code from production commits.
Scheduling Spikes
• Most spikes are performed spontaneously when a technical uncertainty arises.
• If a spike requires significant effort, the iteration’s slack time usually absorbs it.
• When estimating stories, if research is needed before implementation, include spike
time in the estimate.
• Sometimes, a spike story is created specifically to research and gather information,
which helps in accurate planning and estimation for future development.
5. Explain the Release Planning and its types in Agile technology.
Release planning is the process of deciding what to deliver and when at a high level.
It converts the project vision into a roadmap of working software releases that maximise
business value.
Unlike traditional big-bang planning, Agile release planning is iterative and value-driven: it
focuses on delivering the highest-value features first, then adapting the plan as feedback
arrives.
Key ideas of Agile Release Planning
• Work on one project at a time to avoid task-switching penalties and deliver faster
total value.
• Release early and release often: group the most valuable features first so the product
starts delivering benefits sooner.
• Use Minimum Marketable Features (MMFs) – the smallest sets of functionality
that give real value to customers – to plan small, frequent releases.
• Plans are living documents: they are updated each iteration based on stakeholder
feedback and team velocity.
Benefits:
• Higher return on investment (ROI).
• Early revenue or user feedback.
• Reduced technical and market risk.
• Increased stakeholder trust and visibility.
Types of Release Planning
Although Agile methods use many names, two broad levels are common:
1. High-Level / Long-Term Release Planning
o Sets the overall roadmap for the product.
o Identifies major releases, key MMFs, budgets, and rough timelines for the next
several months or quarters.
o Aligns product vision with stakeholder goals.
2. Iteration-Level (Short-Term) Release Planning
o Done at the start of each iteration or increment.
o Selects which user stories or MMFs will be included in the next small release.
o Uses current team velocity to forecast delivery dates.
o Adjusts priorities based on new feedback.
o
Release planning in Agile is not about fixed deadlines but about maximising value by
delivering small, high-value releases early and often. By using MMFs and updating plans
each iteration, teams can respond to change while maintaining a clear roadmap for
stakeholders.
6. Explain in detail the planning game?
The Planning Game is an XP technique used to create a release plan that maximizes value
while minimizing costs by involving both customers and programmers. It is called a “game”
because it is a structured decision-making process where each participant contributes their
expertise to achieve the best outcome for the team.
Steps of the Planning Game:
1. Story Creation:
o Customers or team members create stories or select unplanned stories that
describe desired functionality.
2. Estimation:
o Programmers estimate the effort (cost) required to implement each story.
3. Prioritization:
o Customers prioritize the stories based on business value, placing high-value
stories first in the release plan.
4. Iteration:
o Steps of estimation and prioritization are repeated until all stories are
estimated and prioritized.
5. Questioning & Discussion:
o Programmers and customers may ask questions to clarify estimates or priorities.
o Each group retains the final say in their area: programmers for effort, customers
for value.
6. Final Plan:
o The outcome is a single, ordered list of stories ready for release.
o Even if stories have equal priority, one is placed first (randomly if necessary).
7. Explain Iteration Planning in Agile/XP.
Iteration planning is the activity of deciding which user stories the team will implement in the
next time-boxed iteration (usually 1 week in XP). It’s sometimes called the “heartbeat” of an
XP project.
Purpose:
• To translate the high-level release plan into a short, achievable plan.
• To give the team and stakeholders a clear commitment about what will be delivered at
the end of the iteration.
• To expose delays early (by fixed time-boxes).
How It Works:
1. Timebox the iteration
Iterations are fixed-length (e.g., 1 week). Work stops at the deadline regardless of
how much is finished. This reveals problems early instead of letting them accumulate.
2. Demo & Retrospective
Start by demonstrating completed stories from the previous iteration and holding a
brief retrospective.
3. Calculate Velocity
Add up the estimates of “done-done” stories from the previous iteration. This is your
capacity (velocity) for the next one.
4. Select Stories
Customers pick the most valuable stories from the release plan up to the team’s
velocity. Split or adjust stories if needed.
5. Break Stories into Tasks
Programmers brainstorm concrete engineering tasks (2–6 hours each) needed to
complete those stories.
6. Estimate Tasks
Estimate each task in ideal hours; split tasks bigger than 6 hours.
7. Commitment Ceremony
The whole team reviews the plan and each member explicitly commits (“yes”) to
delivering the stories.
8. Track & Adjust
Post the plan in an “informative workspace.” Track daily progress. If emergencies
arise, swap equal-sized work or handle them with a dedicated “batman.”
Key Principles:
• Fixed deadline, flexible scope (timeboxing).
• Customer involvement (story selection, clarifying requirements).
• Transparency (public task board).
• Collective ownership (everyone commits and can raise concerns).
• Slack built in for surprises.
Benefits:
• Regular delivery of working, tested software.
• Early warning when work is taking longer than expected.
• Builds trust with stakeholders through predictable delivery.
• Reduces “death by inches” — small delays accumulating unnoticed.
8. Slack in Extreme Programming (XP)
In XP, slack means intentionally leaving a small amount of time in each iteration for non-
urgent but important work. It acts like “extra cord length” in the power-cord metaphor—
protecting the plan from random bumps so the team can still deliver its commitments on time.
Why Slack Is Needed
• Randomness, not quantity of problems: If the team always loses exactly 20 hours
per iteration, velocity self-adjusts. But if problems vary from 20–30 hours, velocity
bounces and commitments are at risk. Slack stabilises velocity.
• Prevents overcommitment: Without slack, even small surprises break iteration
commitments.
• Improves long-term productivity: It allows time for paying down technical debt and
research, reducing future delays.
How to Introduce Slack
1. Plan below full capacity
Don’t sign up for more stories than your measured velocity allows. That automatically
includes slack.
2. Schedule non-urgent but useful work
Instead of leaving days blank, plan tasks like:
o Refactoring and cleaning up code.
o Paying down technical debt.
o Building internal tools.
3. Research time
Reserve (for example) half a day per programmer for self-directed learning or spike
experiments. Share results informally.
4. Adjust over time
If velocity is stable, reduce slack slightly. If velocity fluctuates, increase slack.
When Commitments Are at Risk
• Vary the time spent on technical debt first.
• Rarely, use a small amount of voluntary overtime.
• Cancel research time if necessary.
• If you’re doing these every iteration, you’re overcommitted—reduce planned
velocity.
Reducing the Need for Slack
• Make customers more available to answer questions quickly.
• Use slack time to reduce technical debt, which will lower future randomness.
9. Estimating and Velocity in XP
Estimating in XP
Definition:
Estimating is predicting the effort required to complete a story or task. In XP, estimates are
made in ideal engineering days (story points), which assume no interruptions and full focus
on the task.
Key Points:
1. Estimate Effort, Not Calendar Time:
o Interruptions, multitasking, or unexpected issues make calendar time
unreliable.
o Use ideal days/story points to capture “pure” effort.
2. Consistency Over Accuracy:
o Individual estimates may be off, but if consistently applied, the aggregate
results are useful.
o Experts estimate intuitively based on experience; beginners gain accuracy
through practice and repeated iterations.
3. Collaborative Estimation:
o All programmers should participate; at least one on-site customer should be
present to answer questions.
o Discuss unclear aspects of stories, use “??” for unanswered questions, or
create spike stories for research.
4. Iteration Tasks:
o Break stories into concrete engineering tasks and estimate in ideal hours,
including testing, review, and other “done done” requirements.
Velocity in XP
Definition:
Velocity is the number of story points a team can complete in a single iteration. It acts as
a feedback loop to help teams plan realistic workloads.
Key Concepts:
1. Feedback Loop:
o If a team underestimates work, they won’t finish all stories → velocity drops
→ workload decreases in the next iteration.
o If a team overestimates, they finish early → velocity rises → workload
increases in the next iteration.
2. Iteration Timebox:
o Only stories marked “done done” count toward velocity.
o Never extend deadlines or artificially inflate velocity; doing so disrupts the
feedback mechanism.
3. Stabilization:
o Velocity may fluctuate in early iterations; it usually stabilizes after 3–4
iterations.
o Stable velocity enables reliable schedule predictions and better workload
planning.
Improving Velocity
1. Pay down technical debt: Incremental refactoring reduces delays in future iterations.
2. Improve customer involvement: Quick answers reduce waiting and guessing.
3. Support energized work: Avoid burnout and overtime to maintain productivity.
4. Offload programmer duties: Minimize interruptions and administrative work.
5. Provide needed resources: Proper tools and equipment prevent wasted time.
6. Add programmers carefully: Small, experienced teams (6–10) are optimal; larger
teams or new hires may initially reduce productivity.
Tips for Accurate Estimation
1. Estimate in ideal engineering days (story points).
2. Use velocity to determine iteration capacity.
3. Include slack in the iteration to absorb surprises.
4. Apply risk management for long-term planning.
5. Trust your gut for first estimates; adjust only for genuinely new information.
Summary:
Estimating in XP focuses on effort, not calendar time. Velocity is a key metric that tracks
how much work a team can handle, balancing under- and over-estimation. Proper estimation
and velocity tracking, along with slack and refactoring, allow XP teams to plan realistically,
deliver consistently, and improve productivity over time.
10. Explain the Incremental Requirement in agile technologies.
1. Definition:
o Requirements are defined and refined incrementally, alongside development
work.
o Unlike traditional methods, there’s no separate upfront requirements phase.
2. Living Requirements Document:
o On-site customers provide all requirement knowledge directly to the team.
o Face-to-face communication replaces lengthy written documents.
o Notes or sketches may be kept for reference but are informal and concise.
3. Role of Customers:
o Real customers, product managers, and domain experts are involved.
o They clarify expectations, suggest alternatives, and answer developer
questions.
4. Work Incrementally:
o Requirements evolve as stories and features are identified.
o Rough expectations are noted before estimation to help programmers plan
work.
o Detailed requirements, mock-ups, and customer tests are prepared just before
implementation.
5. Mock-ups and Customer Tests:
o Rough UI sketches or prototypes help visualize stories.
o Customer tests ensure correct implementation and understanding of tricky
domain concepts.
o Defines what “done done” means for each story.
6. Customer Review and Feedback:
o Stories are reviewed during development, not after completion.
o Early feedback identifies miscommunication or improvement areas.
o Minor changes can be addressed within iteration slack; major changes become
new stories.
7. Benefits:
o Reduces wasted effort from unnecessary documentation.
o Improves understanding and collaboration between developers and customers.
o Ensures requirements adapt to changing needs and real-world observations.
11. Explain test driven development cycle with an example?
Test-Driven Development (TDD) is a software development practice in Extreme
Programming (XP) where tests are written before writing the actual production code. It
ensures well-designed, well-tested, and maintainable code by following a rapid cycle of
testing, coding, and refactoring.
TDD Cycle (Red-Green-Refactor)
1. Think / Plan:
o Identify the next small behavior or feature to implement.
o Decide on a test that will fail if the behavior is not present.
o Focus on very small increments to simplify debugging and design.
2. Red Bar (Write Failing Test):
o Write a test for the chosen functionality.
o Run all tests; the new test should fail (red) since the feature is not implemented
yet.
o Tests are written from the perspective of the class’ public interface and focus
on behavior, not implementation.
3. Green Bar (Write Production Code):
o Write the minimal code needed to pass the test.
o Do not over-engineer or optimize at this stage; focus on making the test pass.
o Run all tests; they should now pass (green).
4. Refactor:
o Improve the code without changing its behavior.
o Simplify, clarify, and enhance the design.
o Run tests frequently to ensure no functionality is broken.
5. Repeat:
o Start the cycle again with the next small increment of behavior.
o Over multiple cycles, the code grows incrementally with high quality and
minimal defects.
Example of TDD
Suppose we want to implement a class that parses an HTTP query string. Using TDD:
1. Think: Decide on a small increment: count the number of name/value pairs.
2. Red: Write a test for a single name/value pair:
public void testOneNameValuePair() {
QueryString qs = new QueryString("name=value");
assertEquals(1, qs.count());
}
• Initially, QueryString class does not exist, so the test fails.
3. Green: Implement minimal code to pass the test:
public class QueryString {
public QueryString(String queryString) {}
public int count() { return 1; } // hardcoded to pass test
}
• Test passes (green bar).
4. Refactor:
o Improve class design or method names if necessary, without changing
functionality.
5. Repeat:
o Add new tests for multiple pairs, parsing logic, etc., following the same cycle.
12. Explain in detail Exploratory testing is important in Extreme Programming.
1. Definition:
o Exploratory testing is a testing approach where testers simultaneously design
and execute tests, learning from each test to guide the next.
o It aims to discover surprises, untested conditions, and gaps in the software,
rather than exhaustively checking for bugs.
2. Importance in XP:
o XP has no separate QA department; the whole team (customers,
programmers, testers) is responsible for quality.
o The focus is preventing bugs, not just finding them. Exploratory testing helps
the team identify weak spots and improve development practices.
o Testers provide fresh perspectives, finding areas developers may overlook,
including emergent behaviors, unexpected side effects, and cross-story
quality risks like performance, reliability, and security.
3. Philosophy:
o Similar to Test-Driven Development (TDD), exploratory testing avoids
designing an entire test suite upfront.
o Each test is an experiment to understand software capabilities and limitations.
o Provides rapid feedback about the software and the team’s process.
4. Tools and Techniques:
o Charters: Define the goal of a session, e.g., exploring a feature, interactions,
or a quality attribute.
o Observation: Look for anomalies or unusual behavior that automated tests
might miss.
o Notetaking: Record actions and findings to track paths explored and potential
areas for further testing.
o Heuristics: Use rules-of-thumb for testing, such as:
▪ CRUD (Create, Read, Update, Delete)
▪ Boundary/Goldilocks (too big, too small, just right)
▪ Position (beginning, middle, end)
▪ Count (zero, one, many)
▪ Data type attacks and command injection to test robustness.
5. Examples of Exploratory Testing:
o Testing multilingual input, boundary conditions, or unusual data types.
o Discovering bugs in interactions, sorting, format translation, or unexpected
inputs.
o Recording and analyzing results to improve software and process quality.
6. Outcome:
o Bugs discovered are symptoms of process weaknesses, not just software
defects.
o XP encourages team responsibility for bug-free software rather than relying
on testers to remove bugs.
o Helps improve both software quality and team development practices.
7. Key Takeaways:
o Provides insight into untested scenarios beyond automated tests.
o Enables the team to prevent future bugs.
o Supports continuous improvement in XP without creating dependency on
testers.
