|
|
The Scrum planning process sets stakeholders' expectations. These stakeholders include those who fund the project, those who intend to use the functionality created by the project, and those who will be otherwise affected by the project. The plan is a way of synchronizing stakeholders' expectations with the Team's expectations. In the case of stakeholders who will be users of project functionality, the plan helps them organize their work so that they can be ready to take advantage of the functionality as it is implemented. In the case of stakeholders who are funding the project, the plan details their expectation of what funding is required and when the benefits of the project should be realized. The plan is also the basis of project reporting. At the end of the Sprint, the stakeholders attend the Sprint review meetings and compare the project's actual progress against its planned progress. Changes in course and revisions to the plan made in Sprint planning meetings are explained to the stakeholders. For those who are unable to attend the Sprint review meeting, the project reports compare actual results to the plan - both the original plan and the plan as it has been modified since the project's inception.
The Scrum planning process involves resolving three questions:
What can those funding the project expect to have changed when the project is finished?
What progress will have been made by the end of each Sprint?
Why should those being asked to fund the project believe that the project is a valuable investment, and why should they believe that those proposing the project can deliver those predicted benefits?
Scrum projects require less planning than typical Gantt chart-based projects because those working to deliver the expected benefits provide visibility into their progress at the end of every Sprint. Since Scrum projects are too complex to be described in great detail at their inception, we instead monitor them and guide them so that they will deliver the best possible results.
The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is. For a system used internally within an organization, the vision might describe how the business operation will be different when the system is installed. For software that is being developed for external sale, the vision might describe the software's major new features and functions, how they will benefit customers, and what the anticipated impact on the marketplace will be. The Product Backlog defines the functional and nonfunctional requirements that the system should meet to deliver the vision, prioritized and estimated. The Product Backlog is parsed into potential Sprints and releases, as illustrated in Figure 6-1.
One of the purposes of the plan is to convince someone to fund the project. The plan should provide sufficient details to satisfy a source of funding that the project has merit, that it will deliver certain things at certain times, that the benefits outweigh the costs and risks, and that the people who will staff the project are sufficiently compentent to execute the plan.
Scrum is often implemented well after the project in question has been planned. In the case of these projects, the funding is already in place and expectations have already been established. What's necessary now is to replan the project in light of Scrum so that the Team, Product Owner, and stakeholders can envision the project as a series of Sprints that lead to a release, all driven by the Product Backlog. The first task is to create the Scrum artifact needed for managing a Scrum project: the Product Backlog. The following section describes an example of such a project.
|
|
