Datasheet

10
❘
CHAPTER 1 SHIPPING SOFTWARE
You need a well - developed product backlog. The backlog items must be ranked into a list, based
on the value they deliver to the customer. By looking at the prioritized backlog, you can identify
the fi rst set of backlog items to implement. You might even be able to identify the second or
third set of related backlog items. In other words, by working with the backlog, you can make a
reasonable estimate of how much you can get done within a fi xed time period. Your estimate is
for a fi xed time period with a fi xed team, but the feature set that you deliver will vary. The Scrum
approach therefore meets the goals of budgetary control and also addresses the realities of software
development with respect to unknowns.
People Planning
Scrum projects are inherently team - driven activities, with all members involved with all aspects
of the project. The team composition is simple, with just 3 roles defi ned. Team size tends to be
small — up to 10 people or so. Because there are so few roles and so few people, team members are
highly interdependent. The individuals on the team will succeed or fail together.
Scrum requires a cohesive team, one that is assembled early in the project and remains consistent
from sprint to sprint. Of course, people will come and go, as families, careers, and projects take us
in unexpected directions, but team consistency is more important in a Scrum project than in other
project management methodologies.
In later chapters, we describe how sprint planning begins with a measure of velocity , the speed at
which a team can implement items on the product backlog. With each sprint, the team estimates the
effort needed to complete a set of backlog items. The team commits to completing the items, and
then it actually does the work. The team ’ s estimates improve with each sprint, as long as nothing
dramatic changes. The measure of velocity becomes more accurate as the team executes sprints.
Changing the team between sprints negatively affects the predictability of the sprints. For instance,
if Manny, Moe, and Jack are replaced with Tom, Dick, and Harry, is it fair to assume that they ’ ll
complete the same amount of work as the original team? Without knowing how much work these
new team members can do, the team will have a diffi cult time committing to backlog items.
While changing team members between sprints is disruptive and negatively affects productivity and
predictability, it ’ s far worse to change team members within a sprint. You should avoid this if at
all possible. Changing people will have a ripple effect not only within the team but also potentially
within the customer base. For instance, if the product owner told some customers that they can see
a feature at the end of a four - week sprint, and team changes within the sprint prevent that feature
from being complete, the customer will be dissatisfi ed.
As with any other process, it ’ s important that participants know who ’ s supposed to do what and
when. People do well when they know what ’ s expected of them. The alternative — uncertainty —
causes stress. Therefore, you should plan to educate the team on Scrum prior to the project. There
are many good books and resources on Scrum methodologies that you can use to help train the team
on what to expect. Appendix B provides suggestions on where to begin.
Product Features
Time and money — the latter being converted to people and equipment — are the limited resources
for building a product. These resources have a direct relationship to the feature set that ultimately
CH001.indd 10CH001.indd 10 3/23/11 2:46:43 PM3/23/11 2:46:43 PM