Datasheet

2
❘
CHAPTER 1 SHIPPING SOFTWARE
to solve. So, shipping great software really begins with vision and insight into how something
works, how it can be improved, and why people care.
This section discusses the following requirements for shipping software:
Vision
Insight
Resources
Planning
Product features
Vision
Great software starts with a great vision. It starts with a simple description of what you ’ re setting
out to build, for whom, and why. If you can ’ t defi ne this before starting the project, you should
think about it some more. Creating software requires a surprising amount of resources, and you
need to have a compelling vision in order to attract and allocate the resources you ’ ll need.
The vision should be a meaningful description of the product goals and an inspiring outcome. It doesn ’ t
need to be melodramatic — helping the world ’ s neediest people or creating the world ’ s newest
billionaire — but it must resonate with all stakeholders. The vision should describe the needs and benefi ts
in terms that the user cares about. It should describe the problem being solved and the opportunity in
solving it. The vision should pique the interest of customers, sponsors, and the project team.
The product vision should be relatively short; a few paragraphs generally suffi ce. It should include a
description of the problem and opportunity as well as the solution and the benefi t. Everyone on the
project team will read it. They will talk to their colleagues, friends, and families about it. It should
be clear yet comprehensive enough to resonate with these audiences.
The product vision is typically accompanied by a defi nition of scope. The scope clearly sets the
path for the vision, from problem to solution. It should include high - level features, time lines, and
constraints. You can defi ne the scope of a prototype, a beta, and the fi rst few releases. Earlier
milestones should have greater granularity; later milestones can be more vague. The scope should
clearly defi ne what is being proposed and what is not being proposed.
Often, the vision and scope are combined into a single document, cleverly called a vision/scope. This
document is the fi rst opportunity to defi ne a series of releases. Thinking and communicating in terms
of successive releases is critical with Scrum. You can defi ne the rough features that will be in each
release, so everyone learns to expect incremental progress as the team iterates toward the solution.
For example, say you enjoy fantasy football, a game in which you create virtual football teams
that compete based on the statistics of the individual players. The fantasy football sites have great
features for building teams and leagues, but they don ’ t combine that with great search capabilities.
Using Google or Bing for searching just doesn ’ t give you the data you want. In a moment of
inspiration, you decide to fi x the problem by building a search engine for this purpose. You could
create the following vision for this product:
Create a search engine for fantasy sports enthusiasts.
➤
➤
➤
➤
➤
CH001.indd 2CH001.indd 2 3/23/11 2:46:03 PM3/23/11 2:46:03 PM