cards. The strategy is to invest as little as possible to get the most valuable functionality
as quickly as possible. There are three phases in the planning game:
1. Exploration: Find out what the system can do with several so-called moves. The
moves include writing a story, which is done by business personnel. Another move
is to estimate a story, which is done by development personnel who come up with
an ideal engineering time estimate. The estimate does not take into account many
items and assumes no interruptions, meetings, vacations, and so on. A third move
is to split a story if development cannot provide an estimate or if business decides
a specific piece is more important than others.
2. Commitment: Business chooses the scope and date of the next release and develop-
ment commits to delivering it. Here the moves include business sorting the stories
by value into three categories: essential, important, and nice-to-have functional
requirements or stories. Development performs the sorting of stories by risk, again
into three categories: those that can be precisely estimated, those that can be esti-
mated reasonably well, and those that cannot be estimated. Development also sets
what is called the velocity, which is the ratio of ideal time to calendar time. Finally,
the business chooses scope, which is the business requirements expressed on story
cards. This is done through setting a release date and choosing only those story
cards that would fit, or by choosing the story cards and recalculating the dates.
3. Steering: The plan is updated in the steering phase, which consists of several moves
or activities. The first move is at the iteration level, in which business chooses an
iteration’s worth of story cards. The completion of the first iteration should result in a
software system that performs some amount of functions. Recovery is another move.
During this phase, if development realizes it has miscalculated the schedule velocity,
it can ask business to reprioritize the requirements of story cards. A new story may be
introduced if business realizes it needs a new story in the middle of a release. A new
story may replace an existing story or stories with equivalent effort. Reestimate is a
move, or an activity, in which development can reestimate all the remaining stories
and set velocity again, if it feels that the plan needs to be modified.
Within each of the iterations, which are part of a release, the development team inter-
nally subdivides the stories into tasks and carries on a similar planning with the tasks.
Planning is divided into the following tasks:
n
Exploration: The moves are to write a task and to split/combine tasks.
n
Commitment: The moves are to accept a task for which a developer accepts responsibil-
ity, to estimate a task and set a load factor in which each developer estimates his or her
productivity compared with the ideal engineering time, and to balance the tasks for
which programmers add up their tasks and make sure they are not overcommitted.
n
Steering: This phase includes the following moves: (1) implement a task, (2) record
progress status where every couple of days programmers are asked about their task
status and remaining workload, (3) recovery where overcommitted programmers may
ask for help, and (4) verify story, which is essentially executing the functional tests for
the story. The steering phase of the iteration contains some moves that are more than
planning. It actually includes performing the tasks and readjusting the plan for the
iteration, if necessary.
90 Chapter 5 New and Emerging Process Methodologies
91998_CH05_Tsui.indd 90 1/10/13 12:13:16 PM