Planning encompasses effort spent identifying, prioritizing, and assigning work for an entire project. This includes work scheduled within a specific iteration and work spanning multiple iterations. Planning continues until the project is complete.
The project vision statement describes the project goals and what will be accomplished.
The project vision statement describes the project goals and what will be accomplished. It is the guide for making scope decisions throughout the project and should be approved by the project sponsor.
The project vision statement is recorded in the "Vision Statement" section of the Project Charge Document (M101) used in the Project Management methodology. A project vision statement is typically written as a sentence-style observation similar to the following:
The problem of [provide a description of the problem] affects [identify the people affected by the problem] , the impact of which is [explain how those people are affected]. A successful solution would [discuss the benefits of the proposed solution].
Iteration forecasting is a high-level method of viewing story cards across iterations and releases.
Iteration forecasting is a top-down view of story cards when they are grouped by project goals or phases that are scheduled across multiple iterations and multiple releases of the entire project. This planning activity is helpful when release dates are fixed and scope and/or resources can be adjusted to meet the fixed release dates. The iteration forecast is a deliverable that can be shared with stakeholders to communicate release dates, resource capacity, and high-level iteration schedules within each release.
A meeting takes place once per iteration to estimate (for the next iteration) the number of hours each story card will take to complete.
Project estimating occurs once per iteration. A meeting is conducted to review story cards and provide estimates to prepare for future iterations. An estimate should not take more than one to two minutes per card; it is a best guess based on the information at hand.
Ideally, multiple estimates should be captured (if possible) to derive the median estimate, which is then documented on the story card. A set number of estimating factors (2, 4, 8, 16, & 32) are used. Pick the larger number if the card does not provide enough information. Do not spend time designing the work described on the story card during estimating. If an estimate is not feasible (because of new functionality, new technology, and so on) use a time boxing approach for a new story card to further evaluate the effort.
A risk rating is a project team member’s certainly level about the project hours for a story card. Risk rating options are high, medium, or low. For example, if a project team member estimates eight hours to finish a story card but is unsure the estimate is accurate, risk rating of “high” would be applied.
The standard estimate sheet includes:
A planning game is an exercise conducted with the stakeholder to choose which story cards will be worked for an iteration.
Stakeholders choose which story cards will be worked for an iteration by going through a planning exercise. The project manager works with the stakeholder to select the story cards based on the goals for the iteration, priorities and resource capacity or budget. Together they prioritize and select which cards will be worked in that iteration based on the total capacity of the project team.
The planning game can be conducted in various ways. At a minimum, the following information is needed:
ITS project teams using Microsoft Team Foundation Server (TFS) will download the story cards (i.e., features) into Excel where the project manager selects the cards for the iteration based on the development capacity and priority. The Excel file is passed back to the development manager for assignment to team member based on their individual availability.
ITS project teams using SharePoint download the list of story cards to Excel. Cards are printed and are selected for the iteration based on priority and capacity.
Poker chips or colored stickers can also be used to communicate weight and/or importance of story cards for a series of iterations that make up a release. Project teams working under this approach provide the story cards to the stakeholders and ask the stakeholders to designate a ‘chip’ rated from 1 -5 (with 5 being the most urgent and 1 the least urgent) to five of the story cards. Project team members are also given an opportunity to designate a ‘chip’ on the same set of story cards, but they may only select three cards. The results are compiled by adding the chip values for all story cards that are designated by more than one person. The sum of the card defines the weight of each card (highest value card gets worked on first). When this planning game process is used for a release, it is important to complete the process prior to the majority of the development effort of the current release. This allows the project team to begin working on the next release immediately.
An additional approach is to create planning sheets that represent available capacity for the iteration (excluding off time, internal activities and production support; the M-Reports project team uses 70% of normal work hours for the iteration, then reduces that amount for individual vacation and holiday time) and then place the story cards by their priority and estimate into the available hours on the sheets. For example, if there are 32 hours of available time per person for the iteration, then one 32-hour story card or any combination of story cards up to 32 hours might be played.
The project manager or resource manager (i.e., the development or BSA lead) assigns the story cards to project team members once the planning game is complete. The assignments will be based on the median estimate for the assigned story card and their capacity for the iteration.
Assignments are made and communicated via either TFS, the wall or a SharePoint list.
Stakeholders play a critical role in iterative development and must be willing to commit to a substantial role in the process.
Stakeholder participation is critical both for successful planning and to the ITS Iterative software development approach. Stakeholders must be able to commit to the following:
The ideal stakeholder is the sponsor who represents the financial commitment to the project or the sponsor’s delegate. Customers may participate as stakeholders. However, they are usually best utilized as subject matter experts who do not represent a project decision-making authority but rather who participate in interviews and test designs (keeping in mind target persona).
An iteration is a one- to four-week cycle during which a set of story cards is worked on , the result of which is a deliverable of functionality.
An iteration is a one- to four-week cycle during which a specific set of story cards is worked on as authorized by the project stakeholder. The actual length of the iteration is based on team throughput but should be as short and sustainable as possible. The result of the iteration is a deliverable, such as functioning software, that can be released but not necessarily deployed to production.
Iterations mitigate risk by promoting small feedback loops that help stakeholders and teams make course corrections early on in the development process. The outcome is business value that is delivered early and regularly.
A release is the process of moving code to production; agile teams release as often as is sustainable.
Release describes the action of moving code from a non-production environment to production. A release can occur at the end of every iteration, or it can be the combination of several iterations of work.
Risk is reduced when agile teams release as often as is sustainable. For example, one team may release quarterly while another team releases bi-weekly. Both are acceptable depending upon the throughput of the project team and the project’s timeline. However, it is recommended that releases occur at least quarterly to avoid missed opportunities to receive timely feedback that would support expedient delivery of business value.
The Parking Lot is a place where pre-approved work is stored in case planned work for the iteration is completed ahead of schedule.
Stakeholder-approved work that can be pulled ahead if all work within the planned iteration for that lane is complete and all other lanes are on target. Story cards in the parking lot are displayed outside of the lanes on the wall. If parking lot story cards are not worked on, they are re-estimated and prioritized with all other story cards as part of the planning game for the next iteration.
See The Wall sample
The release backlog consists of story cards initially identified to potentially meet release goals. Story cards written but as of yet unassigned (not on the wall) are also included.
This technique supports making a decision at the point in time where failing to do so results in a decision by default. Making a decision as late as possible supports making the most informed possible choice. Horizontal planning/last responsible moment is most effective when iterations are short enough to allow for fast feedback loops.
The time boxing approach establishes a fixed-duration assignment period up front. The work must stop when the duration ends regardless of whether the assignment is completed. Time boxing is used often on agile-managed projects to conduct research into potential solutions for specific problems. It is important to specify on the story card that the work is expected to be time boxed.
See Project Vision Statement sample
Name, identify, and define a project scope and requirements
Outline roles and responsibilities identified for the project. Identify training requirements associated with each role.
See Planning Game sample
See Estimating sample