186 CHAPTER ◆ 2 0 Plan and Document Technology Specifications
● Facilitate transfer to new users or new machines.
● Serve as a basis for enhancement.That is, an SRS can evolve, providing a foundation for continuous evaluation and
improvement.^220.2. Collaborative Planning
High technology changes quickly and software development, therefore, is not completely
predictable. Development teams that are agile embrace change, even while user requirements
are fixed, creating first a release plan, and then a series of iteration plans as they progress.
A release plan in K | V consists of the SRS and a forecast as to when the development
team believes it can complete implementation. A release planning meeting should include
all members of both the product team and the development team. In this way, the release
plan will communicate a shared vision for the project between the product team and the
development team.
An iteration plan lays out the design-build-test scenario for each piece of the system,
tackling the features with the highest business priority and risk first. Each iteration, that is,
loop in K | V, of Stage 3 strives to implement a small enough feature or set of features, in
fine enough granularity, so the team can confidently estimate time and effort required. If a
feature cannot be completed in a single loop, the development team should break it down
into smaller pieces. The team leader uses timeboxed iteration cycles to track progress
of completed tasks and features as development progresses. In general, we recommend
shorter iterations, at most two weeks. Shorter loops force better team communication and
performance through more frequent:● Contact regarding project risks.
● Iteration planning meetings.
● Teamwide reflection after each loop.
● Informal and formal code reviews.
● Daily scrum meetings.The development team should also create a management plan to define the procedures for
software development control processes, such as configuration management and versioning.20.2.1. Running a Successful Iteration Planning Meeting
At each iteration planning meeting, the development team breaks down features into
tasks and assigns tasks to team members. The product team should attend this meeting
to answer questions and prioritize the remaining work. During the meeting, development
team members volunteer for tasks and as they finish them, sign up for more. Often, after
collective brainstorming, the development team leader will list ranked tasks on a white-
board or cards. (Subsequent daily scrum meetings are then held in view of the whiteboard
or the posted cards.) When team members complete tasks, they erase them or cross them
out. The same process can be used for project risks as well.
Given customer priorities, we recommend ranking tasks by risk, or uncertainty.
Uncertainty can be in the form of technological complexity, amount of effort, interdepart-
mental politics, or user testing of the interface. The development team should also consider