marij

Questions:
UNIT-I — Introduction to XP & Agile

Most Expected Questions

[Link] Agile. Explain why Agile is required in software development.

[Link] Agile vs Traditional (Waterfall) development.

[Link] the Agile Manifesto and its 4 values.

[Link] 12 Agile principles with explanation.

[Link] is Extreme Programming (XP)? Explain its key values and practices.

[Link] XP Life Cycle with a neat diagram.

[Link] between Scrum vs XP.

[Link] Pair Programming and its benefits.

[Link] is Collective Code Ownership?

[Link] Energized Work in XP.

[Link] Informative Workspace with examples.

[Link] are Retrospectives? Why are they important?

[Link] is Root Cause Analysis in XP?

[Link] for choosing/ adopting XP in a project.

[Link] Thinking (in XP) and how it improves design.

[Link] importance of Beyond Deadlines in Agile development.

[Link] is Agility vs Agile methods?

Unit II — Collaborating

[Link] collaboration in agile/XP and list its key practices.

1
marij

[Link] the role of trust in agile teams. Give examples of how to build and maintain
trust.

[Link] does "sit together" mean in XP/agile? Describe benefits and limitations
(especially for distributed teams).

[Link] real customer involvement and why it is essential. How is it achieved in

practice?

[Link] ubiquitous language and explain how it helps team communication (give a
short domain example).

[Link] stand-up meetings: purpose, typical format (3 questions), and best

practices.

[Link] are coding standards? Why are they important for collaborative development
and collective ownership?

[Link] is an iteration demo (iteration review)? What does it accomplish and who
attends?

[Link] kinds of reporting (progress/status reporting) are useful for agile teams and
stakeholders? Give examples.

[Link]/contrast collaboration practices (sit together, stand-ups, iteration demo)

with a traditional/non-agile team — focus on customer feedback and communication
flow.

[Link] challenges in implementing collaborating practices (e.g., remote teams,

unavailable customers) and propose solutions.

[Link]/definition style: “Give one sentence each for — Trust; Sit together; Real
customer involvement; Ubiquitous language; Stand-up meetings; Coding standards;
Iteration demo; Reporting.”

UNIT-III — Releasing

Most Expected Questions

[Link] is a Bug-Free Release? Explain the practices that ensure it.

[Link] Version Control and its role in Agile teams.

2
marij

[Link] is Ten-Minute Build? Why is it important?

[Link] Continuous Integration (CI) with workflow.

[Link] of Continuous Integration in XP.

[Link] Collective Code Ownership and its benefits.

[Link] is Documentation in Agile? Contrast heavy vs light documentation

[Link] between Release Planning vs Iteration Planning.

[Link] Incremental vs Big-Bang Release.

[Link] in Agile release management.

UNIT-IV — Planning

Most Expected Questions

[Link] is Release Planning? Explain with steps.

[Link] Planning Game in XP.

[Link] User Stories with format & examples.

[Link] is Story Estimation? Techniques (Planning Poker / Story Points).

[Link] Iteration Planning and its activities.

[Link] is Risk Management in Agile projects?

[Link] the concept of Slack and its importance.

[Link] between Velocity vs Burndown Chart.

[Link] Versioning in XP/agile projects.

[Link] planning is more flexible in Agile than Waterfall?

[Link] short notes:

-Epic vs Stories vs Tasks

-Relative Estimation

3
marij

-Time-boxing

UNIT-V — Developing

Most Expected Questions

[Link] Incremental Requirements.

[Link] is Customer Testing? Give examples.

[Link] Test-Driven Development (TDD) with flow diagram.

[Link] advantages & challenges of TDD.

[Link] Refactoring and explain with examples.

[Link] is Incremental Design & Architecture?

[Link] Spike Solutions.

[Link] between Exploratory Testing vs Scripted Testing.

[Link] is Performance Optimization in XP?

[Link] involved in XP development cycle.

[Link] Acceptance Testing vs Unit Testing.

[Link] is Simple Design Principle in XP?

UNIT I — Introduction to XP & Agile

1. Define Agile. Explain why Agile is required in software development.

(10 Marks)

A. Definition of Agile

Agile is a collection of iterative and incremental software development approaches

that aim to deliver value quickly and continuously by embracing change. Agile is guided
by the Agile Manifesto, which emphasizes individuals and interactions over
processes and tools, and responding to change over following a rigid plan. Extreme

4
marij

Programming (XP) is one of the most popular and well-known approaches in the family
of agile methods.

B. Why Agile is Required in Software Development

Agile addresses the inherent flaws and limitations of traditional, sequential

development methods (like Waterfall), particularly in complex projects:

1. Embracing Change: Traditional methods treat change as an expense and try to

avoid it. Agile is required because it welcomes changing requirements, even
late in development [search]. This flexibility is crucial in dynamic markets
where customer needs and technology evolve rapidly.
2. Continuous Delivery of Value: Agile delivers working software frequently in
small increments (from a couple of weeks to a couple of months). This provides
early return on investment and allows users to gain value sooner, making
working software the key measure of progress.
3. Risk Reduction: By delivering small increments and involving customers
continuously, potential problems, technical issues, and misunderstandings are
identified and resolved early. This minimizes the risk of a catastrophic failure at
the end of the project.
4. Enhanced Customer Involvement: Agile mandates continuous feedback and
involvement of customers for developing good-quality software. This close
collaboration ensures the final product truly meets the customer's business
needs.
5. Focus on People and Communication: Agile prioritizes individuals and
interactions and prefers face-to-face communication over documentation.
This direct, fluid communication reduces misinterpretations and speeds up
decision-making.

2. Compare Agile vs Traditional (Waterfall) development. (10 Marks)

The core differences between Agile (like XP/Scrum) and Traditional (e.g., Waterfall)
development lie in their approach to requirements, flexibility, customer involvement,
and delivery pace.

Agile Development (XP,

Feature Traditional Development (Waterfall)
Scrum)
Adaptive and Iterative.
Predictive and Sequential. Focuses
Philosophy Focuses on flexibility and
on strict planning and phase
customer needs. Responding

5
marij

to change over following a completion. Following a plan over

plan [search]. responding to change [search].
Incremental and Evolving.
Comprehensive and Fixed. Requires
Requirements are gathered in
Requireme detailed, complete documentation of
small chunks (User Stories)
nts all requirements up front. Change is
and welcome changing
seen as costly and risky.
requirements, even late.
Frequent and Early. Working
Single, Large Delivery. Working
software is delivered in small,
Delivery software is delivered only at the very
frequent increments (weeks
end of the project (Big-Bang Release).
to months).
Collaborative and Negotiating and Phase-Based. The
Customer Continuous. The customer is customer is involved only at the
Role an active, continuous part of beginning (requirements) and the end
the team (on-site customer). (acceptance).
Simple Design. Design Elaborate Design Up Front (BDUF).
improves with time Attempts to design for all possible
Design
(Refactoring) and only focuses future scenarios, leading to
on immediate needs. complexity.
Completing documentation or
Progress Working software is the
phase-gate milestones is the primary
Measure primary measure of progress.
measure of progress.

3. Explain the Agile Manifesto and its 4 values. (10 Marks)

A. The Agile Manifesto

The Agile Manifesto is a formal declaration created in 2001 by a group of software

developers. It defines the set of 4 values and 12 guiding principles for effective
software development [search]. It is a foundational document for all Agile
methodologies, including XP and Scrum.

B. The 4 Core Values (with Explanation)

The Agile Manifesto states that while there is value in the items on the right, we value
the items on the left more:

1. Individuals and interactions over processes and tools

a. Explanation: This value prioritizes people, communication, and
collaboration as the most critical drivers of success. Tools and rigid
processes should support the team, not dictate how they work. Direct,
6
marij

fluid conversation among talented, motivated individuals is more

effective than scheduled, documentation-heavy communication
[search].
2. Working software over comprehensive documentation
a. Explanation: The true measure of progress is tangible, functional
software, not the volume of paperwork. While documentation (like User
Stories) still exists, the focus is on delivering executable features that
provide value to the customer immediately. Lengthy documents are often
outdated, misleading, and a poor method for conveying information.
3. Customer collaboration over contract negotiation
a. Explanation: Successful development requires working with the
customer continuously throughout the project, rather than strictly
sticking to a contract negotiated months or years ago. This close
partnership ensures the product remains aligned with the customer’s
evolving business needs.
4. Responding to change over following a plan
a. Explanation: This is the heart of agility. It acknowledges that change is
inevitable and valuable [search]. Rather than treating change as an
expensive deviation to be avoided, Agile embraces it as a competitive
advantage that improves the project's final outcome.

4. Discuss 12 Agile principles with explanation. (10 Marks)

The four values are supported by 12 Principles that guide Agile development practices:

1. Customer Satisfaction: Our highest priority is to satisfy the customer through

early and continuous delivery of valuable software.
2. Welcome Change: Welcome changing requirements, even late in development.
Agile processes harness change for the customer's competitive advantage.
3. Frequent Delivery: Deliver working software frequently, from a couple of weeks
to a couple of months, with a preference to the shorter timescale.
4. Business-Developer Collaboration: Business people and developers must
work together daily throughout the project [search].
5. Motivated Individuals: Build projects around motivated individuals. Give them
the environment and support they need, and trust them to get the job done
[search].
6. Face-to-Face Conversation: The most efficient and effective method of
conveying information to and within a development team is face-to-face
conversation.

7
marij

7. Working Software as Progress: Working software is the primary measure of

progress.
8. Sustainable Pace: Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a constant pace
indefinitely (like a marathon, not a sprint) [search].
9. Technical Excellence: Continuous attention to technical excellence and good
design enhances agility [search].
10. Simplicity: Simplicity—the art of maximizing the amount of work not done—is
essential. Focus on delivering the simple system that works now.
11. Self-Organizing Teams: The best architectures, requirements, and designs
emerge from self-organizing teams [search].
12. Reflect and Adjust: At regular intervals, the team reflects on how to become
more effective, then tunes and adjusts its behavior accordingly (Retrospectives).

5. What is Extreme Programming (XP)? Explain its key values and

practices. (10 Marks)

(Answer based on the detailed response from the previous turn, incorporating
external search for complete values/principles not fully detailed in the source, but
maintaining focus on the source's concepts.)

A. Definition of Extreme Programming (XP)

Extreme Programming (XP) is one of the most important software development

frameworks within the family of Agile models. It is a highly disciplined methodology that
takes the best practices of software development to "extreme" levels—for example, if
code review is good, XP uses pair programming (continuous code review). It focuses on
delivering high-quality software through frequent and continuous feedback,
collaboration, and adaptation.

B. Key Values of XP (from research and source)

XP is traditionally based on five core values:

1. Communication/Listening: Developers must listen carefully to customers and

use tools like a Ubiquitous Language to ensure accurate understanding.
2. Simplicity: The main principle is to develop a simple system that works
efficiently in the present time, avoiding speculation on future requirements.
3. Feedback: Frequent contact with the customer and continuous testing provides
rapid feedback, helping the team understand the exact needs.

8
marij

4. Courage: The courage to change design (refactor), discard non-working code,

and speak the truth about progress.
5. Respect: Mutual respect among team members, customers, and stakeholders
is vital for effective collaboration and success [search].

C. Key Practices (Activities)

XP practices drive technical excellence:

• Pair Programming: Two developers work together at the same workstation to

code and review in real-time.
• Test-Driven Development (TDD): Writing and executing test cases before
writing the production code to continually reduce defects.
• Continuous Integration (CI): Developers build and integrate their code several
times a day, often to a central repository, to find interface bugs early.
• Collective Code Ownership: Everyone shares responsibility for the code
quality, and anyone can make necessary changes anywhere.
• On-site Customer: A real customer works with the team full-time to provide
immediate answers and clarifications.
• Refactoring: Continuously improving design quality without changing external
behavior to eliminate "bug breeding grounds".

6. Explain XP Life Cycle with a neat diagram. (10 Marks)

The Extreme Programming (XP) life cycle is iterative and incremental, revolving around
delivering a working, testable system frequently. It consists of five main phases:
Planning, Designing, Coding, Testing, and Listening (Feedback).

XP Life Cycle Diagram

Explanation of Phases:

1. Planning (The Strategy):

a. Activity: The process starts with the customer providing requirements in
the form of User Stories (short descriptions of desired features).
b. Outcome: The development team estimates the effort required for each
story. Together, the customer prioritizes stories, and the team creates a
Release Plan (what features will be delivered and when) and an Iteration
Plan (what to build in the next few weeks).
2. Designing (The Simple Solution):

9
marij

a. Activity: Developers focus on creating the simplest design that will work
efficiently now.
b. Practice: This phase is heavily integrated with Coding and uses Spike
Solutions (simple programs to explore technical suitability) and
Refactoring (continuous design improvement). Complex design
documentation is avoided.
3. Coding (The Build):
a. Activity: This is where the actual code is written in very short cycles.
b. Practices: Key XP practices are strictly enforced: Pair Programming
(real-time code review) and Test-Driven Development (TDD), where a
test is written before the code. Coding Standards are followed to
maintain uniformity.
4. Testing (The Verification):
a. Activity: Testing is constant and integrated throughout the cycle.
b. Practices: This involves automated Unit Tests (written by developers)
and Acceptance Tests (Customer Tests). Continuous Integration
ensures that all new code works with the existing system.
5. Listening (The Feedback Loop):
a. Activity: The team regularly seeks feedback from the customer and
stakeholders.
b. Practice: This is done via the Iteration Demo (review of the completed
increment). The feedback gathered immediately feeds back into the
Planning phase to adjust priorities and requirements for the next
iteration, completing the loop.

7. Differences between Scrum vs XP. (10 Marks)

Scrum and XP are both Agile frameworks that promote iterative development, but they
focus on different aspects of the process. Scrum is a project management
framework, while XP is a software engineering framework.

Par
am Extreme Programming (XP) Scrum
eter
Pri
Project Management and Team
mar Technical Practices and Engineering
Coordination. Focuses on
y Excellence. Aims to improve code quality
framework, roles, and time
Foc and rapid adaptability [search].
management [search].
us

10
marij

Iter
atio
Typically shorter, often 1 to 2 weeks long Typically 2 to 4 weeks long
n
[search]. [search].
Len
gth
Cha
Very high. Changes (e.g., swapping a Low/Strict. Changes are not
nge
feature of equivalent size) are highly allowed into the sprint backlog
Tole
amenable within an iteration, provided once the Sprint Planning Meeting
ran
work hasn't started [search]. is finished [search].
ce
Key Mandatory ceremonies: Sprint
Mandatory technical practices: Pair
Pra Planning, Daily Scrum (Stand-
Programming, TDD, Refactoring,
ctic up), Sprint Review, Sprint
Continuous Integration.
es Retrospective [search].
Clearly defined roles: Product
Rol Fewer formal roles: Customer (On-Site),
Owner, Scrum Master,
es Developer, Coach [search].
Development Team [search].
Cod Code quality and engineering
Quality assurance is a built-in,
e practices are typically left to the
continuous discipline (TDD, Pair
Qua self-organizing Development
Programming).
lity Team to define [search].

8. Explain Pair Programming and its benefits. (10 Marks)

A. Definition of Pair Programming

Pair programming is a collaborative XP practice where two developers work together at

one workstation on a single task.

The two developers switch roles constantly:

1. The Driver: Writes the code, focusing on the immediate goal and typing.
2. The Navigator: Continuously reviews the code, thinks strategically, identifies
errors, and suggests design improvements.

B. Benefits of Pair Programming

Pair Programming supports several XP values and enhances team productivity and
code quality:

11
marij

1. Breaks Down Knowledge Silos: By switching partners and roles frequently,

knowledge about different parts of the codebase spreads throughout the team.
This prevents any single person from becoming the sole expert, or "gatekeeper,"
of a specific module, thus supporting Collective Code Ownership.
2. Real-Time Code Reviews: The navigator provides immediate, continuous
feedback, suggesting improvements and ensuring design consistency as the
code is being written. This built-in review mechanism enhances quality and
reduces bugs before the code is committed.
3. Improved Code Quality: Two minds working on the same problem tend to
produce better, simpler solutions. This practice reduces the number of defects
generated.
4. Enhanced Communication and Trust: Working closely together fosters fluid
communication and builds mutual respect and trust between team members.
5. Encourages Consistent Style: Pairs naturally align on coding style and
conventions, making the entire codebase more uniform and understandable for
any team member who needs to work on it later.
6. Better Focus and Problem Solving: The presence of a partner helps the driver
stay focused and less likely to get stuck on a difficult problem, as the navigator
can suggest different approaches.

9. What is Collective Code Ownership? (10 Marks)

A. Definition

Collective Code Ownership is an XP practice where everyone shares responsibility

for the quality of the code and anyone can make necessary changes anywhere in
the entire system. No single developer "owns" a module or file, and no one needs
permission to improve any part of the software.

B. Importance and Benefits

1. Reduces Knowledge Silos: It prevents the problem of "knowledge silos," where

only one person understands a crucial part of the system. This improves team
resilience if a key member is unavailable.
2. Facilitates Refactoring: Since everyone owns the code, a developer who
encounters poor design (a "bug breeding ground") in any part of the system is
empowered and expected to Refactor it immediately to improve its clarity and
quality.

12
marij

3. Increases Bus Factor: It ensures that knowledge about different parts of the
codebase is widely distributed. This is supported by practices like Pair
Programming and Continuous Integration.
4. Enables Problem Solving: Collective ownership allows the team to solve
problems no matter where they may lie in the system. If a problem is found, the
team collectively addresses it, rather than waiting for a specific resource.
5. Shared Responsibility: Successes and failures are shared, not assigned to
individuals, fostering a culture of mutual support and accountability.

10. Describe Energized Work in XP. (10 Marks)

A. Definition and Context

Energized Work (or Sustainable Pace) is an XP practice rooted in the Agile principle
that states: "Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace indefinitely"
[search].

Energized Work focuses on maintaining high productivity over the long term by
ensuring developers are rested, engaged, and free from chronic pressure.

B. Core Components and Principles

1. No Overtime Culture: XP strictly discourages working excessive overtime

[search]. Overtime is seen as a short-term patch that ultimately leads to
burnout, reduced quality, and slower long-term productivity. The goal is a 40-
hour work week [search].
2. High Quality (No Technical Debt): Energized work is sustained by high-quality
code. The commitment to relentless Refactoring and TDD ensures the team is
not constantly fighting technical debt, which is exhausting and demotivating.
3. Trust and Motivation: The team must be composed of motivated individuals
who are trusted to get the job done [search]. When people are trusted and
treated with respect, they are naturally more energetic and focused.
4. Breaks and Rest: Developers are encouraged to take short breaks when needed
to maintain focus. The emphasis is on quality of output during focused hours,
not sheer quantity of hours worked.

13
marij

C. Benefits

• Reduced Defects: A tired developer makes more mistakes. Energized, rested

developers produce higher-quality code, reducing the defects that drain future
energy.
• Sustainable Pace: The team avoids burnout and can maintain a reliable,
consistent level of output, which is crucial for accurate Release Planning.
• Improved Team Morale: Fosters a healthy and positive team culture, which
makes other collaborative practices (like Pair Programming and Retrospectives)
easier to implement.

11. Explain Informative Workspace with examples. (10 Marks)

A. Definition

An Informative Workspace is an XP practice that structures the team’s physical (or

digital) environment to make the state of the project immediately visible and accessible
to everyone—team members, customers, and stakeholders—at a glance. It acts as a
large, physical dashboard for the project.

B. Key Principles

1. Transparency: The goal is to maximize the transparency of work flow, process,

and progress, supporting the Agile value of open collaboration.
2. Shared Understanding: It ensures that everyone is literally "on the same page"
regarding what is being worked on, what is blocking progress, and what the
team’s priorities are.
3. Encourages Collaboration: The workspace is designed to facilitate quick, face-
to-face communication.

C. Examples of Artifacts (Physical or Digital)

• Task/Kanban Board: A physical or digital board (e.g., using sticky notes) clearly
showing the state of work for the current iteration, categorized into columns like
To Do, In Progress, Testing, and Done.
• Product Backlog/Stories: Large cards or documents that list all remaining User
Stories for the project, prioritized by the customer.
• Radiators: Information displayed prominently (on a monitor or whiteboard) that
"radiates" key data, such as:

14
marij

o Burn-down Charts: Showing the work remaining in the current iteration

[search].
o Build Status: A visible indicator (often a traffic light or screen) that turns
RED immediately when the Continuous Integration build fails, prompting
the team to fix it urgently.
o Team Velocity: A chart showing the team's average delivery capacity
[search].
o Definition of Done: A clear, visible checklist defining when a feature is
truly complete.
• Sit Together: The most essential component is the team literally sitting
together (co-location in an open space) to facilitate fast, accurate
communication.

12. What are Retrospectives? Why are they important? (10 Marks)

A. Definition of Retrospectives

Retrospectives are formal, recurring meetings held at the end of every iteration (sprint)
in Agile frameworks. They provide a structured opportunity for the team to reflect on
the past iteration and continuously improve their processes, collaboration, and
delivery.

B. Main Objective

The main objective is to Inspect and Adapt—to identify what worked well, what didn't,
and what the team will change moving forward.

C. Importance (Benefits)

1. Continuous Improvement (Kaizen): Retrospectives help teams identify and

address bottlenecks, inefficiencies, or pain points that hinder their work, leading
to increased productivity and efficiency in subsequent iterations.
2. Enhanced Collaboration and Trust: They foster a safe space for the team to
share honest feedback without placing blame. This strengthens mutual trust and
helps identify issues hindering team dynamics.
3. Actionable Changes: The outcome of a retrospective is not just a discussion
but a commitment to concrete, actionable steps for the next sprint. The team
ensures that insights are turned into practical process changes.

15
marij

4. Fosters Team Ownership: By giving every team member a voice in shaping the
way they work, retrospectives promote autonomy and ownership over the
development process (Self-Organizing Teams).
5. Learning from Experience: Retrospectives provide a vital mechanism to learn
from both successes (what to keep doing) and failures (what to change).

13. What is Root Cause Analysis in XP? (10 Marks)

A. Definition and Context

Root Cause Analysis (RCA) is the formal process of identifying the fundamental
reason—the root cause—for a problem (like a bug, defect, or process failure), rather
than merely addressing the superficial symptom. In XP, RCA is highly important
because the goal is to fix the underlying design flaws that breed more bugs.

B. Application in XP

1. Defect Prevention: When a defect is discovered, the XP team's goal is not just
to fix the bug, but to prevent it from ever happening again. RCA is used to
determine:
a. Why did the code allow this bug? (Poor design/Refactoring needed)
b. Why did our process not catch this bug earlier? (Test coverage/TDD gap)
2. Fixing the Process: The insights from RCA are used to Fix the Process itself. For
instance, if a category of mistake is found repeatedly during Exploratory
Testing, the team must use RCA to figure out the systemic failure and make that
type of mistake impossible to repeat in the future.
3. Refactoring Integration: RCA often reveals that the root cause of repeated bugs
is technical debt (complicated, confusing code). This directs the team to use
Refactoring on the offending code sections to reduce future risk.

C. Techniques (Implied)

A common technique for simple RCA is the "Five Whys," where the team repeatedly
asks "Why?" until the fundamental process or design flaw is identified. The result of the
RCA informs the next set of stories or refactoring tasks.

16
marij

14. Criteria for choosing/ adopting XP in a project. (10 Marks)

XP is not a universal fit; it is best suited for projects that align with its practices and
values. The criteria for choosing or adopting XP are:

1. Change is Expected/Welcome: XP is highly effective when requirements are

vague, volatile, or expected to change frequently [search]. It is designed to help
teams adapt to fast-changing requirements [search].
2. Small-to-Medium Teams: XP practices (especially Pair Programming and
intense communication) are most efficient for teams that do not exceed 12
people [search]. Managing small groups is easier, and communication is more
efficient [search].
3. High Customer Availability (On-Site Customer): XP requires a real customer
involvement who is available full-time to provide immediate answers and
feedback. If the customer cannot be constantly involved, XP is a poor choice.
4. Technically Risky Projects: XP practices, such as TDD and Continuous
Integration, help teams avoid problems connected with working on a new
system or facing strict technical deadlines [search]. The high level of customer
engagement reduces the risk of the customer not accepting the end product
[search].
5. Organizational and Team Discipline: The team must be highly disciplined and
dedicated to following core practices like TDD, Pair Programming, and relentless
Refactoring, as these rules are non-negotiable [search].
6. Need for High Quality: When delivering high-quality, defect-free software is a
critical priority, XP’s strong engineering practices are mandatory [search].

15. Explain Thinking (in XP) and how it improves design. (10 Marks)

A. Definition of Thinking in XP

In the context of XP, Thinking is not a separate phase of long-term planning, but rather
the continuous, integrated process of focusing on Simple Design and using iterative
refinement to improve the software's structure.

XP rejects the idea of Big Design Up Front (BDUF). Instead, it relies on two core
"Thinking" mechanisms:

1. Simple Design: Always implement the simplest system that will work now,
avoiding effort on speculations of future requirements. The principle is to think
about the immediate need, and nothing else.

17
marij

2. Relentless Refactoring: Continuous design improvement that happens daily.

B. How Thinking Improves Design

• Focus on Immediate Value: By thinking about the simplest system that passes
all current tests, the team avoids over-engineering and keeps the design
lightweight and flexible.
• Design Emerges Incrementally: Good quality design is important, but XP
ensures that design is not just a one-time event; everybody should design daily.
The design emerges over time through small, incremental changes [search].
• The Power of Refactoring: The act of Refactoring forces the developer to
understand the unfamiliar code and makes the design clearer for the next
person. Refactoring fixes underlying design flaws that accumulate as technical
debt, ensuring the design remains simple, clear, and easy to maintain over the
project's lifespan.
• Test-Driven Design: TDD forces the developer to think about how the code will
be used (tested) before it is written. This leads to code that is inherently more
modular, cohesive, and easy to test—all hallmarks of good design.

16. Explain importance of Beyond Deadlines in Agile development. (10

Marks)

A. Definition and Context

The "Beyond Deadlines" concept in Agile is tied directly to the Sustainable Pace
principle (or Energized Work) and is a rejection of chronic, unrealistic deadlines and
forced overtime. It argues that a successful project prioritizes predictability and
quality over a single, arbitrary date. The delivery dates are decided by empowered
teams of talented individuals.

B. Importance in Agile

1. Maintains Sustainable Pace: Agile aims to maintain a constant, steady pace

indefinitely (a marathon, not a sprint) [search]. Working beyond a sustainable
pace leads to burnout, high turnover, and poor health, which ultimately
compromises the project's long-term success.
2. Ensures Code Quality: When teams are constantly rushed, they skip crucial
steps like Refactoring and fully implementing TDD. This results in technical
debt—complicated code that is hard to fix later—meaning short-term speed

18
marij

leads to long-term slowness. The commitment to technical excellence

enhances agility [search].
3. Predictability and Trust: A team operating at a sustainable pace can
consistently deliver what they commit to in each iteration. This consistency
allows for accurate Velocity tracking and more reliable Release Planning,
building trust with stakeholders [search].
4. Better Estimation: Empowered teams who are not pressured to commit to
impossible dates can give honest, accurate estimates. In XP, the team
determines how much work (stories) they can take on. The customer then
chooses the scope based on the team's capacity.

In essence, Agile moves the goalpost from hitting a date (which often compromises
quality) to hitting a pace (which guarantees a predictable, high-quality flow of
features).

17. What is Agility vs Agile methods? (10 Marks)

A. Agility (Mindset)

Agility is the abstract concept, the philosophical mindset, or the organizational ability
to respond effectively to change.

• Definition: It is the organizational culture, capability, and mindset characterized

by adaptability, flexibility, speed, and continuous learning. It is rooted in the
four values and twelve principles of the Agile Manifesto [search].
• Focus: It is about why you work this way—prioritizing value, trust, and
continuous improvement. It encompasses the attitude of the entire organization,
from executive strategy down to the individual team members.

B. Agile Methods (Frameworks)

Agile methods (or methodologies) are the concrete, practical frameworks, practices,
and toolsets used to achieve agility.

• Definition: These are the established prescriptive processes that guide a team's
day-to-day work.
• Examples: Extreme Programming (XP) (focusing on technical excellence),
Scrum (focusing on project management, roles, and time-boxing), and Kanban
(focusing on flow and limiting Work-in-Progress) [search].
• Focus: They are about how you work—using sprints, daily stand-ups, pair
programming, and velocity metrics.
19
marij

C. Relationship

Agility is the goal; Agile methods are the means to achieve it. A team might use an Agile
method like Scrum, but if they lack the underlying agility (e.g., they still punish mistakes
or refuse to welcome changing requirements), they are merely doing "pseudo-Agile"
and missing the core benefits.

UNIT II — Collaborating

1. Define collaboration in agile/XP and list its key practices. (10 Marks)

A. Definition of Collaboration in Agile/XP

Collaboration in Agile methodologies (like XP) is defined as the close, continuous, and
effective interaction among team members and with stakeholders. It relies heavily on
the Agile value of individuals and interactions over processes and tools. The team's
goal is shared ownership, transparency, and rapid alignment, achieved through
frequent, direct communication.

B. Key Collaboration Practices

The provided source material lists eight key practices to help a team and its
stakeholders collaborate efficiently:

1. Trust: Essential for the team to thrive, enabling psychological safety and self-
organization.
2. Sitting Together (Co-location): Leads to fast, accurate, and fluid
communication, which reduces misunderstandings.
3. Real Customer Involvement (On-site Customer): Helps the team deeply
understand what to build by providing immediate answers and clarification.
4. Ubiquitous Language (UL): A shared set of domain-specific terms that helps all
team members (developers, customers, testers) understand each other
perfectly.
5. Stand-up Meetings (Daily Scrum): Short, focused meetings that keep team
members informed of progress, blockages, and next steps, promoting
transparency and quick problem resolution.
6. Coding Standards: Provides a template for seamlessly joining the team’s work
together, ensuring uniformity and supporting collective code ownership.
7. Iteration Demos (Review): Keeps the team’s efforts aligned with stakeholder
goals by reviewing completed, working software at the end of each iteration.

20
marij

8. Reporting: Helps reassure the organization and key stakeholders that the team
is working well, providing transparency on progress and business value.

2. Explain the role of trust in agile teams. Give examples of how to build
and maintain trust. (10 Marks)

(Answer based on the detailed response from the previous turn.)

A. Role of Trust in Agile Teams

Trust is fundamental and essential for the team to thrive and perform well.

• Psychological Safety: Trust creates an environment where team members feel

safe to speak up, admit mistakes, or challenge decisions without fear.
• Autonomy: Trust is the backbone of autonomy, allowing the team to be self-
organizing and make decisions about their work.
• Mutual Respect: Team members need to trust that they will be treated with
respect when they ask for help or disagree.
• Organizational Confidence: The larger organization needs to trust the team to
deliver successfully, especially since XP often uses progress indicators
managers are unaccustomed to seeing.

B. Examples and Practices to Build and Maintain Trust

1. Transparency and Accountability:

a. Transparency: Share information openly, both good and bad, about
progress and blockers.
b. Consistency and Accountability: Do what you say you’ll do, own
outcomes, and learn from mistakes.
2. Building Empathy (Sitting Together):
a. Sitting Together is the most effective way to build empathy, as
customers and programmers see that the others are working hard.
b. Customer-Programmer Trust: Programmers must respect customer
goals; customers must respect programmer estimates and technical
recommendations.
3. Process-Based Improvement:
a. Retrospectives: These help build trust, provided the team can avoid
placing blame.
b. Energized Work: Trust is easier to maintain when coupled with energized
work, as the team avoids burnout and rushed mistakes.

21
marij

3. What does "sit together" mean in XP/agile? Describe benefits and

limitations (especially for distributed teams). (10 Marks)

A. Definition of "Sit Together"

Sitting Together (or Co-location) means arranging the workspace so that all team
members (developers, testers, and the on-site customer) are physically located
together in an open space. It is one of the core practices that leads to fast, accurate
communication.

B. Benefits

1. Fast, Accurate Communication: It facilitates fluid, face-to-face

communication, which is the most efficient and effective method of conveying
information. A developer can instantly ask the on-site customer for clarification,
getting an answer in seconds instead of hours via email.
2. Builds Empathy and Trust: By seeing each other work, each group (customers,
programmers, testers) develops mutual respect and sees that the others are
working hard, which builds trust.
3. Encourages Collaboration: It facilitates practices like Pair Programming and
impromptu brainstorming sessions.
4. Rapid Problem Resolution: Blockers or technical difficulties can be resolved
almost instantly by simply turning around and asking the person who knows the
answer.

C. Limitations (especially for Distributed/Remote Teams)

1. Impractical for Distributed Teams: The primary limitation is that physical co-
location is impossible for distributed or remote teams [search].
2. Loss of Fluidity: For distributed teams, the rapid, implicit communication is lost
and must be artificially created using tools (like video conferencing, shared
digital whiteboards, and continuous chat/collaboration tools).
3. Time Zone Challenges: Significant time differences can make real-time
collaboration (like stand-ups or pair programming) difficult or impossible.

Solution for Distributed Teams: The principle of "Sit Together" is upheld by

maintaining high-bandwidth digital connectivity. Teams use tools like Jira, Slack, and
Miro to remain digitally connected and maintain transparency and alignment.

22
marij

4. Explain real customer involvement and why it is essential. How is it

achieved in practice? (10 Marks)

A. Definition of Real Customer Involvement

Real Customer Involvement, typically implemented as the On-Site Customer practice

in XP, means that a real user or business representative works with the team full-
time, every day. This person represents the business and user needs and acts as the
sole source of requirements for the development team.

B. Why it is Essential

1. Prevents Misunderstandings: It helps the team deeply and immediately

understand what to build. Ambiguities in requirements are resolved in seconds
through face-to-face conversation, rather than becoming costly bugs later.
2. Prioritization: The customer makes constant, real-time decisions about the
priorities of the User Stories, ensuring the team is always working on the feature
that provides the maximum business value.
3. Continuous Feedback: The customer reviews and Accepts or rejects
completed stories at the end of each iteration. This continuous feedback
ensures the product is on track and avoids late-stage surprises.
4. Fixes Bugs and Defects: Working closely with stakeholders helps prevent
requirements-oriented defects from being written in the first place.

C. How it is Achieved in Practice

1. Co-location: The customer physically sits together with the development team.
2. Writing User Stories: The customer is responsible for writing the User Stories
that define the system's functionality.
3. Iteration Demos: The customer attends the Iteration Demo to review the
working software and formally Accept the completed features.
4. Acceptance Testing: The customer is often involved in defining and executing
the Acceptance Tests (Customer Tests) that determine if a feature is truly "done
done".

23
marij

5. Define ubiquitous language and explain how it helps team

communication (give a short domain example). (10 Marks)

A. Definition of Ubiquitous Language (UL)

The Ubiquitous Language (UL) is a shared, domain-specific vocabulary developed by

the team, including developers, customers, and testers. It is a single, agreed-upon set
of terms and definitions used for all conversations, documentation, and code within a
project.

B. How it Helps Team Communication

• Eliminates Ambiguity: It helps team members and stakeholders understand

each other perfectly. By using precise, shared terms, misinterpretations—
which are a major source of bugs and rework—are minimized.
• Aligns Code and Concepts: The terms in the Ubiquitous Language are directly
translated into the naming conventions used in the code (e.g., class names,
function names, database fields). This ensures the software's architecture
directly reflects the business domain, making it easier to read and Refactor.
• Fosters Shared Understanding: Everyone is speaking the same "dialect" of the
project, which is crucial for Collective Code Ownership and transparent Stand-
up Meetings.

C. Short Domain Example

Ubiquitous Language
Concept Confusing Terms (Non-UL)
Term
A registered user’s
User, Client, Customer Object, Profile Member Entity
account
Check-out, Transaction Submission,
Placing an order Enrollment
Buy
The fee paid for a service Cost, Price, Charge Subscription Dues
If the UL term is established as "Enrollment," the code will have a class called
Enrollment, the customer will talk about "Enrollment status," and the database will
have an Enrollment_ID field.

24
marij

6. Describe stand-up meetings: purpose, typical format (3 questions),

and best practices. (10 Marks)

A. Definition and Purpose

Stand-up Meetings (or Daily Scrums) are short, daily synchronization meetings held in
Agile teams. The primary purpose is to promote transparency, alignment, and quick
problem resolution. They are designed to keep team members informed of progress
and to ensure everyone is focused on delivering the current iteration’s goal.

B. Typical Format (The 3 Questions)

The meeting is strictly time-boxed (usually 15 minutes) and is held standing up to keep
it short and focused. During the stand-up, each team member answers three questions
regarding the iteration goal:

1. What did I do yesterday? (That helped the Development Team meet the Sprint
Goal.)
2. What will I do today? (To help the Development Team meet the Sprint Goal.)
3. Are there any impediments (blockers) in my way? (That prevent me or the
Development Team from meeting the Sprint Goal.)

C. Best Practices

• Focus on Blockers: The meeting is not for problem-solving. If a team member

raises a blocker (impediment), only a quick note is made, and problem
resolution is deferred to a separate, post-stand-up meeting (often called a
"parking lot" session).
• Time-Boxed: Strict adherence to the time limit (15 minutes) ensures the meeting
does not become a wasteful status report.
• For the Team, By the Team: The update is aimed at the other team members,
not the manager or Scrum Master. This reinforces self-organization.
• Visibility: Updates often revolve around a visible task board (Kanban or Scrum
board) to promote transparency.

7. What are coding standards? Why are they important for

collaborative development and collective ownership? (10 Marks)

(Answer based on the detailed response from the previous turn.)

25
marij

A. Definition of Coding Standards

Coding standards are a set of rules and guidelines that provide a template for
seamlessly joining the team’s work together. They govern aspects like naming
conventions, file organization, commenting rules, and formatting style.

B. Importance for Collaborative Development

1. Encourages Consistent Style: When pairs or multiple developers work

together, the standards ensure their code aligns on style and conventions. This
makes the entire codebase more uniform and easier for any team member to
read and understand, which is critical for smooth collaboration.
2. Seamless Integration: By providing a standard template, individual work can be
joined together without style conflicts, making the Continuous Integration
process smoother.

C. Importance for Collective Code Ownership

1. Shared Responsibility for Quality: Standards act as the agreed-upon minimum

quality bar. A Continuous Integration (CI) pipeline often automates the
enforcement of these standards. Every developer must ensure their code meets
these standards before it can be integrated, reinforcing the team's shared
responsibility for quality.
2. Code Uniformity: Uniformity means a developer does not need to learn a new
"dialect" for every file they touch. This ease of understanding is the foundation of
Collective Code Ownership, as it ensures that anyone is capable of making
necessary changes anywhere.

8. What is an iteration demo (iteration review)? What does it

accomplish and who attends? (10 Marks)

A. Definition

An Iteration Demo (or Sprint Review) is a meeting held at the end of every iteration
where the development team showcases the working software they have completed
during that period.

26
marij

B. What it Accomplishes

1. Alignment with Stakeholder Goals: It serves to keep the team’s efforts aligned
with stakeholder goals by confirming that the increment of software built is what
the customer actually wanted.
2. Formal Acceptance/Feedback: The primary goal is to get formal customer
acceptance (or rejection) of the completed features. This is the final step where
the customer agrees that the story is "done done".
3. Real-Time Learning: Stakeholders provide invaluable feedback on the delivered
functionality. This feedback immediately informs the priorities and requirements
for the next iteration.
4. Motivates the Team: It is a chance for the team to celebrate their success and
gain recognition for the tangible working software they delivered.

C. Who Attends

• The Development Team: Presents the working software.

• The Customer (Product Owner/On-Site Customer): The key person who
provides feedback and formally accepts or rejects the features.
• Key Stakeholders: Managers, sponsors, sales team, end-users, or anyone else
interested in the product's progress and receiving business value.

9. What kinds of reporting (progress/status reporting) are useful for

agile teams and stakeholders? Give examples. (10 Marks)

Reporting helps reassure the organization that the team is working well. Agile reporting
focuses on tangible results and flow, rather than traditional metrics like hours spent or
adherence to a fixed plan.

Repor
Definition and Focus Usefulness for Stakeholders/Team
t Type
Planning & Forecasting. Used by
stakeholders to estimate how long it
The measure of how many points
will take to complete the remaining
Veloc (work) a team can reliably complete
backlog. Used by the team to
ity in a single iteration on average
determine what they can safely
[search].
commit to in the next iteration
[search].
Burnd Burndown: Shows the work Real-time Progress Tracking.
own/ remaining over time in the current Provides an immediate visual

27
marij

Burn- iteration or project [search]. Burn- indicator of whether the team is on

up up: Shows the work completed over track to meet the iteration goal
Chart time, often including scope [search]. Flat lines signal
s changes. impediments (blockers) immediately.
Organizational Success. Reflects the
Busin The total business value generated fact that software must provide
ess by the software features delivered business value. Assures key
Value (e.g., dollar value, profit). stakeholders that the technically
excellent software is truly valuable.
The number of features the team
can develop in a particular amount
Efficiency and Flow. Measures the
Throu of time. Measured from when the
speed of the value stream. Lower time
ghput team agrees to develop an idea
is better.
until it is in production and
available for use (i.e., Lead Time).
Quality Assurance. Ensures that
A counterbalancing metric to speed is not achieved at the expense
Defec
throughput. Counts the number of of quality. Helps track the
ts
defects found in production. effectiveness of practices like TDD
and Refactoring.

10. Compare/contrast collaboration practices (sit together, stand-ups,

iteration demo) with a traditional/non-agile team — focus on customer
feedback and communication flow. (10 Marks)

Practic
Agile/XP Team Traditional (Waterfall) Team
e
Commu
Structured, Slow, and Document-
nication Fluid, Fast, and Face-to-Face.
Driven. Information flows through
Flow Information is shared instantly
formal channels (emails, status
(Sit and implicitly via co-location.
reports, documents). Communication
Togethe Reduces ambiguity immediately.
requires scheduling.
r)
Custom Continuous and Iterative. Infrequent and Late. Feedback occurs
er Feedback is solicited and acted primarily at the end of major phases
Feedba upon every few weeks during (e.g., after the development phase or
ck the Iteration Demo. Feedback is during final User Acceptance Testing).
(Demo/ immediate and low-cost to Feedback is often high-cost to
Review) incorporate. incorporate.

28
marij

Daily, Short, and Focused on

Weekly, Long, and Focused on
Status Blockers. Updates are for team
Manager. Status reports are compiled
Update members, promoting
and sent up the hierarchy to
(Stand- transparency and self-
management. Focus is on Are we
ups) organization. Focus is on What
hitting the deadline?
is blocking us?
Team Collaboration, shared goals, and Individual task completion and
Focus self-correction. adherence to the original plan.

11. List challenges in implementing collaborating practices (e.g.,

remote teams, unavailable customers) and propose solutions. (10
Marks)

Challe
Impact on Collaboration Solution (Adaptation)
nge
Distrib Cannot achieve "Sit Together," Implement high-bandwidth digital tools
uted/R leading to slow, lower-fidelity (video conferencing, shared boards) to
emote communication and lost maintain digital connectivity. Overlap
Teams empathy. working hours for core collaboration time.
The team loses its sole source
Find a dedicated, empowered Proxy
Unavail of truth, leading to
Product Owner or Business Analyst to act
able assumption-based
as the full-time representative. Refuse to
Custo development, incorrect
start work on stories without customer
mers prioritization, and costly
acceptance criteria.
rework.
Lack of Team members hide mistakes,
Introduce Pair Programming to enforce
Trust/B fear speaking up in
shared risk. Management must eliminate
lame Retrospectives, and avoid
blame and use Retrospectives to focus on
Cultur honest estimates, leading to
fixing the process, not the person.
e low psychological safety.
Coding Enforce Coding Standards. Automate
Friction and time lost in
Style style checks in the Continuous
merging code, frustrating
Conflic Integration (CI) pipeline to provide
Collective Code Ownership.
ts immediate, objective feedback.
Ubiquit New features introduce new
Maintain a visible, living Glossary of all UL
ous terms that conflict with
terms. Review and agree upon new terms
Langua existing ones, leading to
during Stand-ups or Planning Meetings.
ge Drift confusion.

29
marij

12. Short/definition style: “Give one sentence each for — Trust; Sit
together; Real customer involvement; Ubiquitous language; Stand-up
meetings; Coding standards; Iteration demo; Reporting.” (10 Marks)

1. Trust: Trust is the essential foundation for an Agile team to thrive, enabling self-
organization, psychological safety, and mutual respect among all members and
stakeholders.
2. Sit Together: This practice refers to physically co-locating the entire team
(including the customer) in an open workspace to facilitate fast, accurate, face-
to-face communication.
3. Real Customer Involvement: This means having a dedicated on-site customer
working full-time with the team to provide immediate answers, continuous
prioritization, and acceptance of delivered features.
4. Ubiquitous Language: A single, agreed-upon set of domain-specific terms used
consistently by all team members in conversation, documentation, and code,
eliminating ambiguity.
5. Stand-up Meetings: Short, daily, time-boxed meetings that promote team
transparency, keep members aligned on the iteration goal, and quickly raise any
impediments (blockers).
6. Coding Standards: A defined set of rules and guidelines that standardize code
style and conventions, ensuring uniformity and enabling seamless collaboration
and collective ownership.
7. Iteration Demo: A recurring meeting at the end of an iteration where the team
showcases the working software to stakeholders to gain formal customer
acceptance and valuable feedback.
8. Reporting: The practice of using metrics focused on flow and value (like velocity
and throughput) to reassure the organization that the team is working effectively
and delivering business value.

UNIT III — Releasing

1. What is a Bug-Free Release? Explain the practices that ensure it. (10
Marks)

(Answer based on the detailed response from the previous turn.)

30
marij

A. Definition and Goal of a Bug-Free Release

A bug or defect is defined as any behavior of your software that will unpleasantly
surprise important stakeholders. The goal of a Bug-Free Release is to eliminate a
long, separate testing phase by keeping the software in a Production-Ready state at all
times. The strategy allows turning a typical "big release push" into a rapid 10-minute
tap.

B. Practices that Ensure Bug-Free Release (The 6 Pillars)

The Bug-Free Release strategy relies on six interlinked practices:

1. "done done": Ensures that completed work satisfies the stringent definition of
Production-Ready Software, which includes being coded, tested, refactored,
integrated, and formally accepted by the customer.
2. No bugs: A continuous commitment to virtually zero defects, achieved by writing
fewer bugs (TDD/Pair Programming) and fixing bugs quickly when they are found.
3. Version control: Coordinates changes, provides history, and allows team
members to work together without conflicts.
4. A ten-minute build: Ensures that a tested release package can be built in under
10 minutes, making frequent deployment possible.
5. Continuous integration (CI): Prevents a long, risky integration phase by having
developers integrate and test their code multiple times a day.
6. Collective code ownership: Allows the team to immediately solve problems
and refactor design flaws no matter where they may lie in the system.

2. Explain Version Control and its role in Agile teams. (10 Marks)

A. Definition of Version Control

Version Control (or Source Code Control) is a system that records changes to a file or
set of files over time so that you can recall specific versions later. It allows multiple
developers to work on the same codebase simultaneously without disrupting each
other.

B. Role and Importance in Agile Teams

1. Coordinates Change and Collaboration: Version control is fundamental for

Agile Collaboration, as it allows team members to work together without
stepping on each other’s toes. It is the technical backbone that enables
collective work.
31
marij

2. Enables Continuous Integration (CI): CI relies completely on a central

repository managed by version control. Developers frequently update their
working copy from the repository before committing their own changes back,
preventing the accumulation of major integration conflicts.
3. Provides History and Rollback: It keeps a complete, immutable history of the
codebase. If a change introduces a major bug, the team can quickly roll back to
the last known working version, mitigating risk and enabling the No Bugs
principle.
4. Supports Collective Code Ownership: By managing the complexity of merging
different people's changes, version control empowers the whole team to modify
any part of the system, supporting the Collective Code Ownership practice.
5. Facilitates Branching for Features: It allows teams to create isolated branches
for developing new features (based on User Stories), ensuring the main,
integrated codebase remains stable and "production-ready" at all times.

3. What is Ten-Minute Build? Why is it important? (10 Marks)

A. Definition of Ten-Minute Build

The Ten-Minute Build is an XP practice and goal to ensure that a fully tested release
package, including all necessary components (compilation, running unit tests,
deployment scripts), can be completed in under 10 minutes.

B. Why it is Important

1. Enables Continuous Integration (CI): The Ten-Minute Build is non-negotiable

for successful CI. If a build takes too long (e.g., an hour), developers will
integrate less frequently, leading to the return of Integration Hell (long, painful
merge processes).
2. Rapid Feedback: The build process acts as a rapid feedback loop. If a team
commits code and the build fails, the quick feedback (under 10 minutes)
ensures the team can stop immediately and fix the breakage while the code is
fresh in their minds.
3. Supports Deployment Readiness: It gives you the leverage to turn a typical "big
release push" into a rapid 10-minute tap. A fast build means the team can
confidently deploy the "Production-Ready Software" at the end of any iteration,
achieving the goal of the Bug-Free Release.
4. Enforces Automation: Achieving a ten-minute build forces the team to
automate every aspect of the compilation, testing, and installation process,
reducing the risk of manual errors.

32
marij

4. Explain Continuous Integration (CI) with workflow. (10 Marks)

(Answer based on the detailed response from the previous turn.)

A. Definition and Goal of Continuous Integration (CI)

Continuous Integration (CI) is an Agile/XP practice of frequently merging code

changes into a central repository, aiming to detect integration issues and bugs at the
interfaces of different functionalities several times a day. The ultimate goal of CI is to be
able to deploy all but the last few hours of work at any time.

B. CI Workflow (The Iterative Loop)

1. Develop Locally & Write Tests (Red/Green): Developers write code using TDD,
aiming for a successful local build every few minutes.
2. Update Sandbox: Before committing, the developer updates their sandbox
(local working copy) with the latest code from the central repository to ensure
they have the most recent changes.
3. Confirm Local Build: The developer must confirm that the newly updated local
code still compiles and passes all unit and integration tests locally before
committing.
4. Commit Code (Integration): The developer commits their small, functional
changes back to the central repository. This is done multiple times a day.
5. Automated Build & Test (The CI Server): The CI system automatically triggers a
comprehensive build and runs all automated tests (the Ten-Minute Build).
6. Rapid Feedback (Rollback): If the build fails, the team as a whole is responsible
for fixing it immediately. The key XP rule is: You can never let the build break. If
a fix is not instant, the developer must roll back their changes until a fix is
found.

5. Benefits of Continuous Integration in XP. (10 Marks)

CI provides significant benefits by making the integration process small, frequent, and
low-risk:

1. Prevents Integration Hell: It avoids the traditional "integration hell" scenario,

where developers work in isolation for long periods and face a massive, painful,
risky integration phase just before release.

33
marij

2. Rapid Feedback and Bug Detection: By integrating and testing constantly, CI

detects integration issues and bugs immediately (often within 10 minutes). This
allows for a quick fix while the code is still fresh in the developer's mind,
drastically lowering the cost of remediation.
3. Manages Code Conflicts: CI forces developers to handle small merge conflicts
immediately after committing, rather than dealing with massive conflicts weeks
later.
4. Increases Code Confidence: The team can be confident that the main code
branch is always in a working state. This psychological safety is crucial for
Collective Code Ownership, as it encourages developers to modify code
originally written by someone else.
5. Supports Deployment Readiness: CI ensures that the system is always
integrated and testable, which is essential for achieving a Bug-Free Release and
maintaining the ability to deploy at the end of any iteration.

6. Explain Collective Code Ownership and its benefits. (10 Marks)

(See also Unit I, Question 9 for the definition. This response focuses on the
releasing context.)

A. Definition of Collective Code Ownership (CCO)

Collective Code Ownership is an XP practice where everyone shares responsibility

for the quality of the code and anyone can make necessary changes anywhere in
the entire system.

B. Benefits in the Context of Releasing

1. Rapid Bug Fixing: CCO allows the team to solve problems no matter where they
may lie in the system. If a developer finds a bug in a system module they didn't
write, they are empowered to fix it immediately, speeding up the path to a "Bug-
Free Release."
2. Enables Relentless Refactoring: CCO forces the team to enforce Coding
Standards and commit to Relentless Refactoring. If a developer finds poorly
designed code (technical debt), CCO ensures they take responsibility ("It's your
code. Fix it!") and refactor it to a state that is simple and maintainable, thus
eliminating bug breeding grounds.
3. Increased Knowledge Sharing: Practices like Pair Programming and
Continuous Integration—which are inseparable from CCO—break down

34
marij

knowledge silos and spread system knowledge widely, making the entire team
resilient and capable of supporting any part of the release.
4. Mitigates Project Risk: It prevents the project from being dependent on a single
individual's knowledge, ensuring that the team can maintain and release the
software even if a key member is unavailable.

7. What is Documentation in Agile? Contrast heavy vs light

documentation. (10 Marks)

A. What is Documentation in Agile?

In Agile, documentation is still necessary, but it adheres to the Agile Manifesto value:
Working software over comprehensive documentation [search]. Documentation
must be just barely sufficient to support the working software and the team's ongoing
collaboration.

The goal of documentation is to decrease its cost while increasing its accuracy.

B. Contrast: Heavy vs. Light Documentation

Fea Heavy (Traditional/Waterfall)

Light (Agile/XP) Documentation
ture Documentation
Phil Comprehensive and Up-Front. Just-in-Time and Necessary. Creates
oso Attempts to document every detail only the documents required for the next
phy before work begins. step or for long-term maintenance.
Cor
Extensive documents: Technical User Stories (the key artifact),
e
Specs, Design Documents (BDUF), automated Test Cases (executable
Arti
Requirements Documents (BRDs), documentation), a visible Task Board,
fact
Interface Documents. and simple Handoff Documentation.
s
Mai Costly to maintain; quickly
Easy to maintain; often embedded
nte becomes obsolete and misleading
directly in the code (e.g., in-line
nan because requirements always
comments, test names).
ce change.
Co
mm Poor method for conveying complex
Favors face-to-face conversation and a
uni information; prioritized over face-
Ubiquitous Language.
cati to-face conversation.
on

35
marij

C. Agile Handoff Documentation (Example of Light Documentation)

When handing the project to another team, Agile recommends creating a small set of
documents recording only the big decisions and nonobvious information. This
summary should include:

• An overview of the project and its design evolution.

• Nonobvious information, such as error conditions, common traps in the code,
and necessary special treatments.

8. Difference between Release Planning vs Iteration Planning. (10

Marks)

Par
am
Release Planning Iteration Planning (Sprint Planning)
ete
r
The short-term planning activity where
The long-term planning activity where
the Team selects a small set of
Def the Customer and Team collaborate to
prioritized User Stories to be
init determine which features (User
completed during the next single
ion Stories) will be delivered in the
iteration (typically 1-4 weeks)
upcoming release cycle [search].
[search].
Ti
me
Long-term (Months to Quarters). Short-term (Weeks). Defines the work
Ho
Defines the overall project roadmap. for the immediate next iteration.
riz
on
Ke
The Velocity of the team and the
y The entire Product Backlog (all known
prioritized items from the Product
Inp User Stories) [search].
Backlog [search].
ut
Ke
An Iteration Backlog (a list of
y
A Release Plan (a forecast of features committed stories) and the Iteration
Ou
and their target release date). Goal (the specific business objective
tpu
for the iteration).
t

36
marij

Capacity and Detailed Tasks. How

Scope and Business Value. What
Foc can the team best complete the
should the product do by a certain
us committed stories in the available
date?
time?
Rol
e
of Available for clarification of the
Prioritizes the stories based on
Cu Acceptance Criteria for the
business value.
sto committed stories.
me
r

9. Explain Incremental vs Big-Bang Release. (10 Marks)

Para
Big-Bang Release
met Incremental Release (Agile/XP)
(Traditional/Waterfall)
er
Releasing small, functional pieces of
Releasing the entire, complete
Defi the software to users frequently and in
product in a single, large launch
nitio a structured sequence. Each release
only at the very end of the
n adds new functionality to the existing
development cycle.
system.
Freq
High (e.g., every 2 weeks, monthly, or Low (e.g., once every 12-24
uen
quarterly). months).
cy
Risk Low Risk. Deployment issues are small High Risk. The entire project's fate
Prof and contained, as only minor changes rests on a single deployment. Any
ile are released at a time. failure is catastrophic.
Fee Late and High Cost. Feedback is
Early and Continuous. Users interact
dba delayed until the product is
with the working software immediately,
ck launched. Changes requested at
providing feedback that shapes the
Loo this stage are extremely costly and
subsequent increments.
p disruptive.
Tim
Rapid. Customers begin realizing value Delayed. Value is realized only after
e to
from core features immediately after the full product is complete and
Valu
the first small release. launched.
e
Sup
Continuous Integration, Ten-Minute Extensive, rigid testing phase at the
port
Build, Bug-Free Release. end.
ing

37
marij

Prac
tice

10. Challenges in Agile release management. (10 Marks)

While Agile streamlines the technical process of releasing, several challenges remain:

1. Defining "Done Done" for Release: The biggest challenge is ensuring that the
definition of "Production-Ready Software" is strictly enforced. If the team
relaxes the criteria (e.g., skipping refactoring or ignoring a known bug), the
stability of the release is compromised.
a. Solution: Use a robust Definition of Done that includes customer
acceptance and passing all automated tests.
2. External Dependencies: Releasing often relies on external groups (e.g.,
marketing, compliance, legal). If these groups operate on a traditional schedule,
they can become a major bottleneck for the Agile team's rapid release cycle.
a. Solution: Involve key external stakeholders in Release Planning and use
the Iteration Demo to keep them aligned and ready for the next release.
3. Maintaining the Ten-Minute Build: As the code base grows, the build time
tends to increase. Teams must be vigilant in constantly monitoring and
optimizing the build script to ensure it remains under 10 minutes.
a. Solution: Dedicate specific time in each iteration (Slack) to optimizing the
build and test suite performance.
4. Managing Technical Debt: Reluctance to stop and Refactor poorly designed
code (technical debt) will eventually make releasing slower and buggier.
a. Solution: Make Refactoring an explicit, daily part of the Coding phase,
using it to eliminate bug breeding grounds.
5. Organizational Pressure for Features: Stakeholders may push the team to
deliver more features (increase throughput) without adequate time for quality
checks, potentially counterbalancing the commitment to low defects.
a. Solution: Use Defects as a counterbalancing metric to Throughput in
reporting to maintain a focus on quality over sheer speed.

38
marij

UNIT IV — Planning

1. What is Release Planning? Explain with steps. (10 Marks)

A. Definition of Release Planning

Release Planning is a high-level, long-term planning activity in Agile development. It

involves the collaboration between the Customer (Product Owner) and the
Development Team to define the overall project roadmap by determining which set of
features (User Stories) will be delivered in the upcoming major release cycles [search].

B. Steps Involved in Release Planning

1. Set Release Goal and Date:

a. The Customer defines the overarching business goal for the release (e.g.,
"Launch our new mobile payment system").
b. A target release date (or fixed time-box) is typically established based on
market needs, although this may be adjusted based on team capacity.
2. Prioritize the Product Backlog:
a. The Customer/Product Owner prioritizes the entire backlog of User
Stories based on business value. Stories providing the most value are
placed at the top.
3. Estimate Stories:
a. The Development Team estimates the effort required for each story,
typically using abstract units like Story Points (Relative Estimation)
[search].
4. Calculate Team Velocity:
a. The team reviews its historical Velocity (the average amount of work
completed in previous iterations) to predict its future capacity [search].
5. Map Stories to Iterations/Releases:
a. The team uses the calculated Velocity to determine which stories (by
effort/points) can fit into each planned iteration within the release
timeframe.
b. The stories are grouped into one or more potential releases until the
release goal is satisfied.
6. Refine and Adjust (The Planning Game):
a. The Customer and Team negotiate the final scope based on the plan. If
the high-priority stories exceed the team's capacity for the target date,
the Customer must either descope (remove lower-priority stories) or
agree to a later date (accept later value).
7. Communicate the Plan:

39
marij

a. The resulting Release Plan is communicated to all stakeholders as a

living forecast, not a fixed contract.

2. Define Planning Game in XP. (10 Marks)

A. Definition

The Planning Game is the primary method of collaborative planning in Extreme

Programming (XP). It is a process that involves a continuous, ongoing negotiation
between two key roles: the Customer and the Development Team [search].

B. The Rules of the Game

The game is structured around three key activities (or rounds):

1. Exploration:
a. Customer's Move: The Customer writes a story card for every desired
feature, detailing the functionality and business value.
b. Developer's Move: The Developer writes a task card for technical
unknowns (Spikes) or estimations for the story cards.
2. Commitment (The Negotiation):
a. Customer's Move: The Customer prioritizes the stories based on the
highest business value and chooses the release date/scope.
b. Developer's Move: The Developer estimates the cost (effort) of the stories
and commits to the scope (how much they can complete) based on their
capacity/velocity [search].
3. Steering (The Adaptation):
a. This is the ongoing process of adjusting the plan as the project
progresses. The team performs short Iteration Planning cycles and uses
Retrospectives to steer the project. New stories are added, priorities
change, and the scope is continuously negotiated.

C. Importance

The Planning Game ensures that the project is always working on the highest-value
features (Customer priority) within a realistic, sustainable timeline (Developer
capacity). It embodies the Agile principle of Customer Collaboration over Contract
Negotiation.

40
marij

3. Explain User Stories with format & examples. (10 Marks)

A. Definition of User Stories

User Stories are short, informal descriptions of a feature written from the perspective
of an end-user or customer. They are the fundamental unit of requirements and
planning in Agile methodologies (like XP/Scrum).

B. Standard Format

User Stories follow a common template to ensure they are user-centric and focused on
value:

As a <type of user>,

I want to <perform some goal/action>,

So that <I can achieve some benefit/value>.

C. Examples

Examp
Format Breakdown
le
Simpl
e As a Registered Member, I want to log in using my email and password,
Examp So that I can access my personal dashboard.
le
Compl
As a Site Administrator, I want to view all current subscription
ex
enrollments in a searchable list, So that I can quickly audit and manage
Examp
payment status.
le
D. The "3 Cs" of User Stories

User Stories are best defined by the 3 Cs:

1. Card: The story is traditionally written on an index card for visibility and
simplicity.
2. Conversation: The details of the story are discussed and clarified through a
face-to-face conversation between the developer and the customer.
3. Confirmation: The final criteria that prove the story is complete are written
down as Acceptance Criteria (the tests that must pass) [search].

41
marij

4. What is Story Estimation? Techniques (Planning Poker / Story

Points). (10 Marks)

A. Definition of Story Estimation

Story Estimation is the process of approximating the effort (complexity, size, and
uncertainty) required to deliver a User Story [search]. Unlike traditional estimation,
which focuses on hours or calendar days, Agile estimation uses abstract measures to
forecast the work.

B. Technique: Story Points

• Definition: Story Points are an abstract measure used to estimate the size of a
user story [search]. They represent the relative effort required to complete one
story compared to others, rather than an absolute measure of time [search].
• Relative Estimation: Estimation is performed relatively—the team compares a
new story to a "base story" they completed previously [search]. For example, "Is
this new story about the same size (1 point), twice as big (2 points), or much
bigger (5 points)?" [search].
• Factors: Story Points account for: the amount of work (volume), complexity
(difficulty), and risk/uncertainty [search].

C. Technique: Planning Poker

Planning Poker is a consensus-based, gamified technique used by the entire

development team to create relative estimates in Story Points.

1. Read Story: The Product Owner reads a User Story and its Acceptance Criteria.
2. Discussion: The team discusses the story, clarifying any ambiguities with the
Product Owner.
3. Silent Voting: Each developer selects a card (often using a modified Fibonacci
sequence: 1, 2, 3, 5, 8, 13, 20...) representing their estimate in Story Points, and
all reveal their cards simultaneously.
4. Discuss Outliers: If estimates vary significantly (e.g., one person votes 3 and
another 13), the high and low voters explain their reasoning (e.g., "I saw high
integration risk," "I thought it was simple because we already built a similar
feature").
5. Re-Vote: The team discusses and re-votes until a consensus (or close estimate)
is reached.

42
marij

5. Explain Iteration Planning and its activities. (10 Marks)

A. Definition of Iteration Planning

Iteration Planning (or Sprint Planning) is a time-boxed meeting held at the beginning of
every iteration. The primary goal is for the Development Team to select the highest-
priority items from the Product Backlog and plan how they will deliver them during the
upcoming iteration [search].

B. Activities (The Two Parts of Planning)

Part 1: The "What" (Defining the Goal and Scope)

1. Review Team Velocity: The team reviews its historical Velocity (capacity) to set
a realistic boundary for how much work it can commit to [search].
2. Product Owner Presents Stories: The Product Owner presents the highest-
priority, estimated User Stories to the team.
3. Team Commits to Scope: Based on its Velocity and confidence in the stories,
the Development Team pulls a subset of stories from the Product Backlog into
the Iteration Backlog.
4. Define the Iteration Goal: The team and Product Owner craft a specific, short-
term Iteration Goal (e.g., "Successfully process a user subscription payment").

Part 2: The "How" (Creating the Tasks)

1. Break Down Stories into Tasks: The Development Team breaks down each
committed User Story into small, technical Tasks (e.g., "Design Database
Schema," "Write Authentication Service Unit Test") [search].
2. Estimate Tasks: Tasks are often estimated in hours (or Ideal Days).
3. Assign Tasks: Team members sign up for tasks. This part reinforces self-
organization [search].

6. What is Risk Management in Agile projects? (10 Marks)

A. Definition and Philosophy

Risk Management in Agile is a continuous, proactive activity focused on identifying,

assessing, and responding to potential threats (risks) that could impact the project’s
ability to deliver value. Unlike traditional risk management, which often involves heavy
documentation, Agile embeds risk management directly into daily practices.

43
marij

B. Continuous Risk Identification (Embedded Practices)

1. User Stories and Acceptance Criteria: Potential risks are identified during the
process of creating user stories and their acceptance criteria.
2. Spikes: Complex or high-risk technical unknowns are addressed using Spikes
(short experiments) before commitment, thereby reducing risk.
3. Historical Data Analysis: Teams review data from previous projects to identify
common patterns and risks relevant to the current one.
4. Retrospectives and Stand-ups: Risks (impediments) are identified and
discussed daily in Stand-ups and systematically reviewed and documented in
Retrospectives.

C. Response and Mitigation Strategies

1. Iterative Adjustments: Risk strategies are adapted as the project evolves and
new information becomes available, supporting the principle of Responding to
Change.
2. Slack: Allocating buffered time (Slack) in the iteration schedule is the primary
proactive response strategy, providing capacity to handle unforeseen risks like
complex bugs or integration issues.
3. Risk Reduction: Risk response activities are broken down into actionable tasks
that can be added to the sprint backlog, similar to user stories or technical
spikes.
4. Transparency: Risks are tracked visually on Scrum boards and communicated
clearly to all stakeholders, fostering a team culture where every member feels
empowered to discuss risks without fear of blame.

7. Explain the concept of Slack and its importance. (10 Marks)

(Answer based on the detailed response from the previous turn.)

A. Definition of Slack (Buffered Time)

In Agile projects, Slack primarily refers to the concept of allocating buffered time in a
sprint schedule. This time is capacity that is not dedicated to specific features but
acts as a buffer for unexpected issues that inevitably arise during a sprint.

B. Importance for Risk Management in Agile

Slack is a critical strategy for mitigating risks, ensuring predictability, and maintaining
the team’s long-term health:
44
marij

1. Accommodating Unexpected Problems: Slack time is used for handling

unforeseen issues such as bugs, integration difficulties, or unexpected
technical challenges that were not planned for in the sprint backlog.
2. Addressing Technical Debt: Teams use this extra capacity to address
technical debt (legacy issues that slow down development), which makes
future work more predictable and efficient.
3. Preventing Over-commitment: By not planning a sprint to 100% capacity,
teams can consistently meet their commitments. This consistency is crucial for
building stakeholder trust and reducing the risk of a project drifting.
4. Increasing Learning and Innovation: Allocating time for learning allows teams
to improve their skills and processes, which, in turn, reduces future risk and
prevents team burnout.

8. Difference between Velocity vs Burndown Chart. (10 Marks)

Velocity and Burndown charts are both essential metrics for tracking and forecasting
project progress, often used together in Scrum/Agile.

Pa
ra
m Velocity Burndown Chart
et
er
De A measure of the amount of work (in A visual representation of the work
fin Story Points) a team can complete and remaining over the course of a single
iti deliver in a single iteration (sprint) on iteration or the entire project
on average [search]. [search].
Ti
m
Historical (Retrospective). Calculated Current (Real-Time). Tracks
e
over the last 3-5 sprints to establish an progress day-by-day within the
Ho
average [search]. current sprint [search].
riz
on
Ke
Forecasting and Planning. Used to Tracking and Correction. Used to
y
estimate how much work the team can see if the team is on track to meet its
Us
commit to in the next sprint and to current sprint goal and to identify
e
forecast the total project duration delays or impediments early
Ca
[search]. [search].
se

45
marij

Vi
The "Actual" line should trend closely
su The value should trend towards a
toward the "Ideal" line, hitting zero
al consistent, stable horizontal average,
(work remaining) by the end of the
Go showing a sustainable pace [search].
sprint [search].
al
W
ar A flat or rising line suggests the
An erratic (jumping) velocity suggests
ni team is blocked, encountering
poor estimation or inconsistent process
ng unforeseen complexity, or has scope
(lack of sustainable pace) [search].
Si creep [search].
gn

9. Explain Versioning in XP/agile projects. (10 Marks)

A. Definition of Versioning

Versioning (or Revision Control) is the process of assigning unique identifiers (version
numbers) to iterations of the software at different stages of development and release.
The core mechanism supporting this is Version Control.

B. Importance in XP/Agile

1. Traceability and Auditing: Each version number uniquely identifies the exact
state of the code, tests, and configuration at a given time. This is crucial for
tracing a production defect back to the specific code version that caused it.
2. Managing Releases: The version number (e.g., 1.0, 1.1, 2.0) clearly
communicates the scope of the Incremental Release to customers and
stakeholders [search].
a. Major Version Change (1.0 to 2.0): Usually indicates a large set of new
features or a significant change in architecture.
b. Minor Version Change (1.0 to 1.1): Usually indicates a new, minor feature
set or set of changes.
c. Patch Version Change (1.1.0 to 1.1.1): Usually indicates only bug fixes.
3. Enables Rollback and Recovery: Versioning, paired with Version Control,
allows the team to precisely identify the last known working version of the
software. If a deployment fails, the team can quickly and safely revert to the
previous, stable version.
4. Supports Continuous Integration: The continuous stream of integrations is
managed by the version control system, which allows the team to "tag" the main

46
marij

branch every time a successful build is completed, creating a deployment

candidate version.

10. Why planning is more flexible in Agile than Waterfall? (10 Marks)

Agile planning is inherently more flexible because it rejects the idea of Big Design Up
Front (BDUF) and operates under the principle: Responding to Change Over Following
a Plan [search].

1. Iterative Cycles (Short Timeboxes): Agile uses short cycles (sprints/iterations

of 1-4 weeks). Planning is performed incrementally for each cycle [search]. If a
plan is found to be flawed after two weeks, only two weeks of work need to be
adjusted, versus months of work in Waterfall.
2. Customer-Driven Reprioritization: The Customer (Product Owner)
continuously prioritizes the Product Backlog based on changing market
conditions or new feedback. This means the Release Plan is a living forecast
that can be reprioritized at any time to focus on the highest-value features
[search].
3. Velocity-Based Commitment: The team commits to work based on its proven
Velocity (capacity), not an arbitrary deadline set by management [search]. If the
team is forced to change direction (flexibility), they can immediately adjust their
committed scope for the next iteration to maintain a sustainable pace.
4. Embracing Change Late in Development: Agile processes not only tolerate but
welcome changing requirements, even late in development [search]. This
inherent openness to change makes the planning flexible enough to pivot
without declaring a project failure. The Planning Game itself is a process of
continuous negotiation and adjustment [search].
5. Refactoring Eliminates Plan Lock-in: The commitment to Refactoring ensures
the design remains simple and adaptable. The design does not become so rigid
that a change in requirements requires a massive overhaul of the foundational
architecture.

11. Write short notes: (10 Marks)

- Epic vs Stories vs Tasks

• Epic: A large, overarching body of work that represents a significant feature or

initiative, often encompassing multiple business goals [search]. An Epic is too

47
marij

large to be completed in a single iteration and must be broken down. Example:

"Implement User Authentication System."
• Story (User Story): A small, functional chunk of work written from the user's
perspective (As a <user>, I want to <goal>...). Stories are small enough
to be completed within a single iteration and deliver immediate value. Example:
"As a user, I want to log in with my email and password."
• Task: A technical, non-user-facing unit of work required to complete a User
Story [search]. Tasks are created during Iteration Planning and are often
estimated in hours. Example: "Design the Member database schema," or "Write
Unit Test for Login function."

- Relative Estimation

• Definition: An estimation technique where the effort of a new work item is

determined by comparing it to similar items previously completed by the team
[search].
• Mechanism: It uses abstract units like Story Points instead of absolute time
[search]. This eliminates the bias and inaccuracy inherent in estimating
unknown work in hours, as human teams are much better at comparative sizing
than absolute sizing.
• Benefit: The estimate is an objective measure of complexity and size for that
team, making it a reliable input for calculating Velocity and subsequent Release
Planning [search].

- Time-boxing

• Definition: The practice of setting a fixed, maximum duration for an activity or

event, and not allowing the activity to continue beyond that set time [search].
• Application: It is fundamental to Agile frameworks. Sprints/Iterations (typically
2-4 weeks) and Stand-up Meetings (typically 15 minutes) are classic examples
of time-boxes [search].
• Benefit: It enforces focus and productivity (prevents analysis paralysis), ensures
predictability in the calendar, and manages risk by cutting off non-essential work
when the time limit is hit.

48
marij

UNIT V — Developing

1. Explain Incremental Requirements. (10 Marks)

(Answer based on the detailed response from the previous turn.)

A. Definition and Context

Incremental requirements are defined, developed, and delivered in small, functional

increments in short iterations. This Agile approach rejects the traditional model of
comprehensive, fixed requirements (Waterfall), which assumes that requirements will
not change. User Stories are the fundamental building blocks of incremental
requirements.

B. Benefits of Incremental Requirements

1. Early and Continuous Feedback: Teams deliver small, working features to the
customer frequently, allowing them to validate assumptions and correct course
quickly. This ensures the final product meets actual needs.
2. Adaptability to Change: Agile processes embrace the reality that requirements
frequently evolve. Incremental requirements provide the flexibility to change
direction based on market trends or new information, even late in development.
3. Reduced Risk and Time-to-Market: By building and testing features in small,
manageable chunks, the risk of a catastrophic failure is minimized. It also
enables a rapid time-to-market for core functionality.
4. Focus on Value: Incremental development forces teams to prioritize and deliver
the features that provide the most value first, ensuring development effort is
focused where it matters most.
5. Better Communication: They eliminate the risks of long, ambiguous, text-heavy
requirements documents by prioritizing direct, face-to-face conversation to
discuss the scope of each increment.

2. What is Customer Testing? Give examples. (10 Marks)

A. Definition of Customer Testing

Customer Testing (also known as Acceptance Testing) is a core XP practice where

tests are created to confirm that a given User Story is working correctly and meets the
customer’s specified requirements. These tests represent the final criteria that
determine if a feature is Accepted by the customer and truly "done done".

49
marij

B. Purpose in XP

• Confirmation: They confirm that the system meets the overall requirements and
business value described in the User Story.
• Contract: They serve as an executable contract between the customer and the
developer. If all Customer Tests pass, the feature must be accepted.
• Regression Prevention: Once automated, these tests become part of the
Continuous Integration system, ensuring that future code changes do not
break existing, accepted features (regression).

C. Examples (Acceptance Criteria)

Customer Tests are often defined as the Acceptance Criteria on the back of a User
Story card.

User Story Customer Test Example

As a Registered GIVEN I am on the login screen and click "Forgot Password,"
Member, I want WHEN I enter a valid email and click "Send Link," THEN I should
to reset my receive an email within 60 seconds containing a unique, one-time
password. reset link.
As an
GIVEN a price is updated in the Admin panel, WHEN I save the
Administrator, I
change, THEN the updated price should appear on the public
want to edit
product page within 5 seconds.
product prices.

3. Explain Test-Driven Development (TDD) with flow diagram. (10

Marks)

A. Definition of TDD

Test-Driven Development (TDD) is an XP development practice in which automated

unit tests are written before any production code is written. It is an iterative cycle
designed to ensure the code is correct, reliable, and easily testable.

B. TDD Flow Diagram

C. The Three-Step Cycle (Red-Green-Refactor)

1. RED: Write a Failing Test (Write Test First)

a. The developer writes a unit test for a new piece of required functionality.

50
marij

b. Since the production code for this feature does not yet exist, the test will
fail (RED) [search]. This step ensures the developer fully understands the
requirements before coding and validates that the test harness is
working.
2. GREEN: Write the Minimum Code (Make Test Pass)
a. The developer writes just enough production code (the simplest possible
code) to make that newly written test pass (GREEN) [search].
b. The focus is purely on functionality and speed, not elegance or perfect
design. All other existing tests must also still pass.
3. REFACTOR: Clean Up the Code (Improve Design)
a. Once all tests are GREEN, the developer cleans up (refactors) the code.
This involves eliminating duplication, improving naming conventions, and
simplifying the design, all while continuously re-running all tests to
ensure no existing functionality is broken [search].
4. Repeat: The cycle immediately begins again for the next small piece of
functionality.

4. Write advantages & challenges of TDD. (10 Marks)

A. Advantages of TDD

1. Higher Code Quality and Fewer Defects: TDD is a proven technique for
reducing the number of defects generated. Because tests are written first, the
code is continuously verified and less prone to errors.
2. Simpler, Testable Design: TDD forces the developer to consider how the code
will be used and tested from the outset. This naturally leads to code that is more
modular, cohesive, and easy to test—hallmarks of Simple Design [search].
3. Executable Documentation: The tests themselves serve as a form of
executable documentation, showing exactly how each component is supposed
to behave.
4. Enables Refactoring: The comprehensive suite of tests created by TDD acts as
a safety net [search]. This allows the team to perform Relentless Refactoring
with confidence, knowing that if they accidentally break existing functionality,
the tests will immediately turn RED.
5. Programmer Confidence: Developers gain high confidence in the code's
correctness, which is essential for Collective Code Ownership [search].

51
marij

B. Challenges of TDD

1. Initial Time Investment: Writing tests first can initially feel slower, leading to
resistance from developers new to the practice.
2. Requires Discipline: TDD requires high team discipline to follow the Red-Green-
Refactor mantra consistently, especially under deadline pressure [search].
3. Testing External Systems: Unit tests should focus on isolated components. It is
challenging to write unit tests for code that heavily interacts with external, non-
deterministic systems (like databases, APIs, or UIs) without using complex
mocks or fakes [search].
4. Risk of Testing Implementation, Not Behavior: If developers test too much of
the internal structure (implementation details), the tests become fragile and
must be rewritten every time the code is refactored, reducing the agility of the
test suite.

5. Define Refactoring and explain with examples. (10 Marks)

(Answer based on the detailed response from the previous turn.)

A. Definition and Purpose of Refactoring

Refactoring is a core "Developing" practice in XP defined as the process of improving

design quality without changing the external behavior or functionality of the code. It is
performed continuously and in small steps, ideally after the code has passed its tests
(the GREEN phase of TDD).

B. Role and Benefits in XP

Refactoring is essential for long-term project health and for eliminating technical debt
(complicated, confusing code that breeds bugs).

• Eliminates Bug Breeding Grounds: Its primary purpose is to fix underlying

design flaws and structural problems, which are the root cause of repeated
bugs.
• Enables Collective Ownership: Relentless Refactoring ensures that all code
remains simple and readable, allowing any team member to confidently modify
it.
• Improves Comprehension: The act of refactoring unfamiliar code forces the
programmer to understand it, benefiting the next person who works on the code
by making the design clearer.

52
marij

C. Examples (Implied Refactoring Activities)

1. Extract Method: Taking a large block of code within a function and moving it into
its own, small, well-named function to improve clarity.
2. Rename Variable/Class: Changing unclear names (e.g., tmp or proc) to
meaningful names (e.g., memberEnrollmentProcess).
3. Eliminate Duplication: Merging two similar code blocks or functions into a
single, reusable component.
4. Move Field: Moving a field or variable to a more appropriate class or module to
improve cohesion.

6. What is Incremental Design & Architecture? (10 Marks)

A. Definition

Incremental Design and Architecture is the practice of developing the software's

design and structure iteratively over time, in alignment with the Incremental
Requirements. It follows the XP principle of Simple Design—design only for the needs
of the current User Story and continuously Refactor the architecture as new
requirements emerge.

B. Contrast with Traditional (BDUF)

It rejects the traditional Big Design Up Front (BDUF) model, which attempts to create a
complete, rigid design to anticipate all possible future requirements. BDUF is risky
because the extensive design is based on faulty initial assumptions and is costly to
change.

C. How it Works (Emergent Design)

1. Initial Simple Design: The team creates an initial architecture that is just
sophisticated enough to handle the first few high-priority stories.
2. TDD and Refactoring Drive Design: The design evolves organically based on the
Relentless Refactoring and the local design decisions made during the TDD
cycle. TDD forces modularity, and Refactoring keeps the design simple.
3. Spikes Explore Complexity: When a design decision involves significant
technical unknowns, the team uses a Spike Solution to research the best
architectural approach before committing to the design.

53
marij

4. Testability as a Constraint: The entire architecture is constrained by the need

for testability (a core advantage of TDD), ensuring that all components can be
easily tested, which is a hallmark of good, modular design.

7. Explain Spike Solutions. (10 Marks)

A. Definition

A Spike Solution (or simply "Spike") is a very simple program, technical experiment, or
short research effort constructed solely to explore the suitability of a proposed
technical solution. It is essentially a prototype designed to solve a specific, high-risk
technical question, not to be delivered to the customer.

B. Purpose

1. Reduce Technical Risk: Spikes are used when a User Story cannot be
accurately estimated because there is a major technical unknown or uncertainty
(e.g., "Will this new database integrate with our existing system?"). The Spike is
run to remove this unknown.
2. Inform Planning: The outcome of a Spike (a clear answer or a small, disposable
prototype) provides the team with the knowledge needed to confidently estimate
the original User Story or to make a critical Architectural Decision.
3. Time-boxed: Spikes are strictly time-boxed (e.g., one or two days) to ensure
they do not become a source of technical debt or over-engineering.

C. Key Principle

Spike code is disposable. The output is knowledge (e.g., "Yes, the new database is
feasible, and it will take 5 Story Points to integrate"), not production code. The team
typically throws away the Spike code and starts fresh with TDD for the actual feature
implementation.

8. Difference between Exploratory Testing vs Scripted Testing. (10

Marks)

(Answer based on the detailed response from the previous turn.)

54
marij

Fea
Scripted Testing
tur Exploratory Testing (ET)
(Traditional/Manual)
e
Ap Dynamic and Unscripted. The tester
Static and Predefined. Execution
pro simultaneously learns, designs, and
follows rigid, detailed, step-by-step
ac executes tests based on intuition and
test cases created long in advance.
h judgment.
Simulating Real-World Usage. Requirement Coverage. Focuses on
Fo Focuses on the tester's skill and verifying that every specified
cus creativity to find unexpected bugs and requirement is met exactly as written
flaws in the process. in the documentation.
Go To expose systemic problems and
To ensure all pre-defined Unit,
al hidden assumptions (e.g., unplugging
Integration, and Customer Tests are
in a network cable) and find new,
finished and passed.
XP unexpected bugs.
Fee
Instant Insights. Creates a quick,
db Slow. Feedback is often delayed until
continuous feedback loop because
ack the test execution phase is completed
testing and design happen
Lo and a report is generated.
simultaneously.
op

9. What is Performance Optimization in XP? (10 Marks)

A. Definition and Philosophy

Performance Optimization in XP is a disciplined practice guided by the principle:

"Don't optimize early, don't optimize for speculation." The team focuses on writing
simple, correct code first, and only optimizes performance when a real performance
bottleneck is identified and measured.

B. When and How to Optimize

1. Measure First: Optimization is done only when profiling tools indicate a specific
area of the system is provably slow, and only in that specific area (i.e., when you
have a performance test that fails). Optimizing code that is already fast wastes
time and introduces complexity.
2. Keep it Simple (Refactoring): XP prioritizes Simplicity and Refactoring over
premature optimization. Optimizing early often involves complex code that is
hard to maintain and prone to bugs, which contradicts the core XP values.

55
marij

3. Spikes for Optimization: If a performance problem is significant, the team may

use a Spike Solution to quickly test and find the most effective optimization
technique before committing to a final, complex code change.

C. Importance

XP prioritizes correctness and clarity first, trusting that small, frequent Refactoring
keeps the code clean enough to be fast. If a part of the system is truly a bottleneck, it is
treated as a Technical Task in the backlog, estimated, and addressed like any other
feature.

10. Steps involved in XP development cycle. (10 Marks)

The XP development cycle is a continuous, repetitive process built around the five life
cycle phases (Planning, Designing, Coding, Testing, Listening), executed in short
iterations.

The continuous loop of an XP development cycle involves these high-level steps:

1. Release Planning (Long-Term): The Customer prioritizes User Stories and the
Team forecasts what can be delivered in the overall release [search].
2. Iteration Planning (Start of Iteration): The Team selects the highest-priority
stories they can complete based on Velocity and breaks them down into fine-
grained Tasks [search].
3. TDD Loop (Daily, Minute-by-Minute): The team executes the core Red-Green-
Refactor cycle:
a. Write a failing Unit Test (RED) [search].
b. Write the simplest code to make the test pass (GREEN) [search].
c. Refactor the code to improve design while all tests stay GREEN.
4. Pair Programming (Continuous): All production code is written in pairs.
5. Continuous Integration (Hourly): Developers frequently integrate their small,
working changes into the main repository, and the Ten-Minute Build runs all
tests.
6. Customer Testing: The On-site Customer defines and executes Acceptance
Tests to confirm the completed stories meet the business requirements.
7. Iteration Demo (End of Iteration): The team presents the working software to
stakeholders for Acceptance and feedback.
8. Retrospective (End of Iteration): The team reflects on the process and adapts
its behavior for the next iteration.

56
marij

11. Explain Acceptance Testing vs Unit Testing. (10 Marks)

Par
am Acceptance Testing (Customer
Unit Testing (Developer Testing)
ete Testing)
r
Go To verify that a single, small unit of To verify that a completed feature
al/ source code (e.g., a function, a class, or (User Story) works correctly and
Foc a method) works exactly as the meets the customer's specified
us developer intended [search]. business requirements.
Wh The Customer (Product Owner or
o The Developer (specifically using TDD) On-site Customer), often with
Wri [search]. assistance from the
tes tester/developer.
Smallest possible scope. Isolated End-to-end functionality. Tests the
Sc
components only, often requiring the system's behavior across multiple
op
use of mocks/fakes for external components (UI, business logic,
e
dependencies. database).
Wh
en Continuously throughout the day (in the At the end of the iteration, before
Exe TDD cycle) and every time the the Iteration Demo, as the final
cut Continuous Integration build runs. check for feature acceptance.
ed
Rol
e in Acts as the final contract for "done
Acts as the safety net for Refactoring
Rel done" and ensures the software is
and code correctness [search].
eas Accepted by the stakeholder.
e

12. What is Simple Design Principle in XP? (10 Marks)

A. Definition

The Simple Design Principle in XP is the commitment to developing a system that has
just enough design to satisfy the current requirements, and no more. It is one of the
core principles that guides the Thinking practice in XP.

57
marij

B. Core Tenets (The Simplest Design Must...)

The simplest design that can possibly work is one that meets four criteria, often referred
to as the 4 Rules of Simple Design:

1. Passes All the Tests: The design must fully implement the requirements and
pass all automated Unit Tests and Acceptance Tests [search]. This is the most
important rule.
2. Contains No Duplication: The design must follow the Don't Repeat Yourself
(DRY) principle. Duplication is a major source of bugs and is eliminated
constantly through Refactoring.
3. Expresses the Intent of the Programmer (Clarity): The code should be easy to
read and understand. Clear names and simple structure are prioritized,
supported by a clear Ubiquitous Language.
4. Minimizes the Number of Classes and Methods: The design should contain
the fewest elements necessary to achieve the goal, avoiding over-engineering or
unnecessary abstractions.

C. Importance

Simple Design ensures the design remains lightweight and flexible, preventing the
team from wasting time on speculative features that may never materialize. By coupling
it with Relentless Refactoring, the team ensures that the design continuously
improves to accommodate new requirements, leading to a long-term, maintainable
architecture.

58