Conclusions

We ‚ ve looked at four examples of a key customer stepping forward to direct the development of software or a product. Through the use of Scrum, each has taken over the role of Product Owner ‚ some knowingly and others unknowingly. In each case, they have learned to collaborate with the Team, Sprint by Sprint, to control the direction and impact of the development effort.

In each case, the ScrumMaster has brought the Product Owner and the Team together. The collaboration has been either explicit or clandestine, but in each case, it was successful. A key element in each example is that the Team and the Product Owner learned to understand each other. Although this might seem easy, the Team and the Product Owner were in fact speaking different languages before Scrum was implemented. The Product Owner had learned to talk in terms of business requirements and objectives, whereas the Team had learned to speak in terms of technology. Because the Product Owner is unlikely to learn the technology, one of the main jobs of the ScrumMaster is to teach the Team to talk in terms of business needs and objectives. The common denominator between the Team and the Product Owner is the Product Backlog.

I have conducted a number of classes over the last year to teach people to become effective ScrumMasters. These classes are referred to as Certified ScrumMaster training. In addition to figuring out how to apply Scrum to various individual situations, we ‚ ve addressed how the ScrumMaster can get the Product Owner and the Team to speak the same language, to use a meaningful common vocabulary to discuss a mutual problem. The attendees are grouped into teams, and they get together to discuss a business problem and present their understanding and recommendations to the Product Owner. These teams almost always present their understanding in ‚“technospeak, ‚½ a language of technology incomprehensible to the Product Owner. When this happens, I show them what they ‚ ve done and help them learn to do otherwise . Through these exercises, I ‚ ve ruthlessly helped future ScrumMasters understand the depths of the language divide that has separated customers and developers. Bridging this gap is critical; if both sides can ‚ t speak the same language, collaboration can ‚ t and won ‚ t occur. The Product Owner has no interest in bridging the gap, and doesn ‚ t have the background to do so anyway, so it is up to the ScrumMaster to help the Team bridge the gap.

In each of the examples in this chapter, the Product Owner and the Team have collaborated to do the best for the business. Each collaboration has resulted in an improved ROI. But how much of an improvement? Without a benchmark against which to measure, such an achievement remains anecdotal. In the next chapter, we will look at how people at the Certified ScrumMaster classes respond when a benchmark for evaluating the ROI of decisions is in place.

Chapter 6: Planning a Scrum Project

Overview

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.

Figure 6-1: Product Backlog

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.