Planning and Tracking

Being a relatively flexible and evolving software development process, there are variations of the XP planning approaches in practice. This page describes the process XPlanner was created to support. The primary features and stages of the planning process are...

Customer and developers define a release plan

XPlanner does not directly support release planning at this time. XPlanner does however allow definition of future iterations and allows stories to be assigned to them. This could be viewed as a form of release planning. In practice, we have also defined pseudo-iterations for future stories that have not been incorporated into an official iteration yet. This allows customers to define product features they'd like to see and provides the raw material for subsequent iteration planning.

Customer defines user stories

User stories are either created in or moved into the iteration being planned. The stories may be prioritized by the customer.

Developers estimate the effort required to implement the stories.

In XPlanner, stories may be given an estimate before tasks are defined. This can be useful for initial rough estimation to determine if it's feasible to implement the set of stories requested by the customer. During the phase, a tracker will sign up to facilitate the development of the story. The tracker usually one of the developers of the story, but that's not a requirement.

Once a feasible set of stories are selected, the developers will define tasks required to implement the story. At this point, the tasks estimates provided by the developers working on the tasks will supersede the rough story estimate. For each tasks, there is an acceptor who is the developer that signed up for the task. When the task is actually performed the acceptor will do the work with a paired programmer.

Developers use a metric based on the prior iteration to determine their budget. The budget determines how much work a developer can accept for the current iteration. In XPlanner, the hours worked for each developer is shown in the iteration metrics window. In general, the number of hours divided by two (to account for pairing) defines a developers budget for the current iteration.

Implement the stories

Assuming the task-based story estimates still fit with the team's budget for the iteration, work starts on the tasks.

Track progress

As tasks are worked, the time spent on those task is tracked. The iteration, story, and task level pages show progress in the form of a progress bar.

The intent of the progress bars is provide a quick overview of team progress (e.g., for a very busy and time-constrained customer). The progress bars are normalized to reduce visual noise on the page. The downside of the normalization is that the relative size of the stories is not shown. This information is included numerically in the iteration table and on other pages. When a task has no hours worked on it, the bar is completely gray.

As hours are worked against the tasks, the progress is shown in blue.

(New for version 0.3) If a task's actual hours exceed the current estimate, the time entry cannot be saved until the task's estimated duration is updated. This is necessary because it's impossible to measure remaining time if a task is over its estimate. Original estimates are not lost so it is possible to generate estimation accuracy metrics.

The story-level progress bars on the iteration page are rollups of the task-level progress.