Extreme Programming - Activities & Artifacts

---

---

In this chapter, we will understand the Extreme Programming activities and artifacts.

XP – Activities

In Extreme Programming, the four basic activities are −

• Coding

• Testing

• Listening

• Designing

Coding

In pair programming, coding is considered the heart of development. You code because if you do not code, at the end of the day you have not done anything.

Testing

In pair programming, testing needs to be done to ensure that the coding is done. If you do not test, you do not know when you have finished coding.

Listening

In pair programming, you listen to know what to code or what to test. If you do not listen, you do not know what to code or what to test.

Designing

In pair programming, you design so that you can keep coding and testing and listening indefinitely, as good design allows extension of the system, with changes in only one place.

These activities are performed during −

• Release Planning

• Iteration Planning

• Implementation

Release Planning

In Release planning, both the customer and the developers jointly arrive at the plan for the next release, agreeing on the user stories for the release and the next release date.

Release Planning has three phases −

• Exploration Phase

• Commitment Phase

• Steering Phase

Release Planning – Exploration Phase

In Exploration phase −

• The customer provides a shortlist of high-value requirements for the system.

• The developers gather requirements and estimates the work impact of each of those requirements.

The Requirements are written down on user story cards. For writing a story, the customer will come with a problem in a meeting with the developers. Developers will try to define this problem and get requirements. Based on this discussion, a story will be written by customer, pointing out what they want a part of the system to do. It is important that the developers have no influence on this story.

Active Listening is significant in this phase, as

• The Developers need to understand "What the customer is asking for" and "What requirements are of high value".

• The customer needs to understand along with the developers about what scenarios contribute to these values to write the story.

Though the customer writes the requirements on user story cards, you need to listen to

• Obtain clarity

• Avoid ambiguity

• Express yourself if there are possible gaps in understanding

This is possible only with verbal communication.

Release Planning – Commitment Phase

In Commitment phase, the customer and developers will commit themselves to the functionality that will be included and the date of the next release.

This phase involves the determination of costs, benefits, and schedule impact. In this phase,

• The customer sorts the user stories by business value.

• The developers sort the stories by risk.

• Developers determine the effort and duration (estimates) required for implementation of the stories.

• The user stories that will be finished in the next release will be selected.

• Based on the user stories and the estimates, the release date is determined.

Active listening is significant in this phase, as −

• The developers need to understand what functionality they need to code for the current release and the effort and duration (estimates) required to deliver this functionality.

• The customer and the developers need to understand the feasibility for commitment on the date of next release.

Release Planning – Steering Phase

In Steering phase the customer and developers "steer" −

• To make changes in individual user stories and the relative priorities of different user stories.

• To adjust the plan.

• If estimates were proved wrong.

• To accommodate the changes.

Active listening is significant in this phase,

• To understand −

  • The new requirements to be added.

  • What changes needs to be done for existing requirements.

  • The impact on the existing system if any of the existing requirements is removed.

• Arrive at the estimates required to adjust the plan, considering

  • The work done so far.

  • The new requirements to be added.

  • Existing requirements that have to be changed or removed.

Iteration Planning

In Iteration Planning, the developers are involved to plan the activities and tasks for the iteration. In this, the customer is not involved.

Iteration Planning has three phases −

• Exploration phase.

• Commitment phase.

• Steering phase.

Iteration Planning – Exploration Phase

In Exploration phase,

• Requirements will be translated to different tasks.

• The tasks are recorded on task cards.

• The developers estimate the time it will take to implement each task.

• If the developers cannot estimate a task because it is too small or too big, they need to combine or split the task.

Iteration Planning - Commitment Phase

In Commitment phase,

• The tasks is assigned to the developers.

• The developer accepts the tasks for which he or she takes responsibility.

• The developer estimates the time it takes to complete the task because the developer is now responsible for the task, and he or she should give the eventual estimation of the task.

• Load balancing is done after all the developers within the team have been assigned tasks.

• A comparison is made between the estimated time of the tasks and the load factor.

• The load factor represents the ideal amount of hands-on development time per developer within one iteration assuming a 40-hour week.

• Then the tasks are balanced out among the developers. If a developer is overcommitted, other developers must take over some of his or her Tasks and vice versa.

Iteration Planning – Steering Phase

In Steering phase,

• The developer gets the task card for one of the tasks to which he or she has committed.

• The developer will implement this task along with another developer following the pair programming practice.

Implementation

The implementation of the tasks is done. The implementation includes design, writing unit tests, coding, unit testing, refactoring, continuous integration to the code base, integration testing and acceptance testing based on the task card and user story card.

Extreme Programming Artifacts

Extreme Programming is not anti-documentation, but encourages doing the least amount that is really needed. The document when needed for distributed sharing, historical needs, summarizing, etc.

The essential Extreme Programming artifacts are −

• User story cards

• Acceptance tests

• Estimates

• Release plan

• Iteration plan

• Task cards

• Design

• Unit test cases

• Customer and developer communication records

User Story Cards

The User story cards have the following features −

• A user story card −

  • Contains a short description of the behavior of the system from the point of view of the customer.

  • Must be written by the customer and not by the developers.

  • Uses the customer’s terminology without technical jargon.

  • Should only provide enough detail to make an estimate of how long the story will take to implement.

• One for each major feature in the system.

• Are used to create time estimates for release planning.

• Drive the creation of the acceptance tests.

Acceptance Tests

Acceptance tests must be one or more tests to verify that a story has been properly implemented.

Estimates – Release Planning

Effort and duration estimates for the stories that will be used in release planning −

• Arrive at the target release date in exploration phase.

• Plan adjustments in steering phase.

Release Plan

Release plan contains −

• The user stories selected for the release.

• Effort and duration estimates.

• Target release date that is committed.

Task Cards

A Task card −

• Contains the required tasks to implement a user story.

• One task card per user story.

• Forms basis for task estimates and task assignments.

Estimates – Iteration Planning

Effort and duration estimates for the tasks based on the user stories are evaluated that will be used in iteration planning for the task assignments and load balancing in commitment phase.

Iteration Plan

Iteration plan contains −

• The user stories selected for the iteration

• Task assignments

• Task estimates

Design

A design contains a simple design just enough for the implementation of a user story.

Unit Test Cases

This contains the Unit Test Cases that drive the coding and unit testing.

Customer and Developer Communication Records

The customer and developers discuss the story to elaborate on the details. It is verbal when possible, but documented when required.