Page 521 - Using MIS

Q6 How Can Scrum Overcome the Problems of the SDLC? 489
Scheduling Tasks

As described so far, scrum is a good idea, one of many agile processes that might be used. What
makes scrum particularly innovative, however, is the way that tasks are scheduled.
Scrum methodology recognizes that developers are terrible, even wretched, at determining
how long a task will take. However, developers are quite good at determining how long some-
thing will take in comparison to something else. So, while a developer may be poor at estimating
the time required to do, say, Task 2 in Figure 12-23, he or she will likely be accurate when saying
that Task 2 will take twice as long as Task 1, or some other ratio.
So, according to the scrum process, once the tasks are known for a given set of requirements,
the next step is to assign each task a difficulty score, called points. The easiest task has a point
score of 1. A task that will take five times longer is given a point score of 5, etc. For reasons that are
beyond the scope of this discussion, points are expressed in values from a sequence of integers
known as the Fibonacci sequence: {1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, and ?}. The question mark is
used because any number larger than 144 is meaningless. Most likely 89 and 144 are meaningless
as well. Tasks with such point scores need to be subdivided into multiple requirements. When all
tasks have received points, the points are summed to a total for the requirement.
Scrum includes several different techniques for assigning points. Team estimation and
6
planning poker are two. You can learn more about them in The Elements of Scrum. The gist
of these techniques is to obtain team scores by applying the team’s expertise in an iterative,
feedback-generating process.

Committing to Finish Tasks

As teams work together, they will learn the total number of points of work they can accomplish
each scrum period. That term is called the team’s velocity. The team uses its velocity to determine
how many requirements it can commit to accomplishing in the next scrum period. Of course, dur-
ing the first period, the team will not know its velocity. In that case, senior members will need to
make a guess. That guess may be far off, but it will get better as the team gains experience. Unlike
the SDLC, there is at least well-founded hope that, over time, estimating will improve.
Suppose the five requirements on a team’s prioritized requirements list total 125 points. If
a team knows its velocity is 100 points per scrum period, it knows it cannot do all five. However,
if the top four total, say 80 points, it can commit to doing those four, plus something else. In this
case, the team would go back to the product owner and ask if there is a requirement lower on
the priority list that can be done for the available 20 points of capacity. This estimation tech-
nique is summarized in Figure 12-24.

Hocus-Pocus?

If you haven’t participated in software or systems development, this process may sound like so
much hocus-pocus. However, it has two very important characteristics that make it not so. First,

1. Team assigns 1 point to simplest task.
2. Times to deliver working tasks are compared to each
other and assigned points (points are Fibonacci numbers). Use:
a. Team estimation
b. Planning poker
c. Other
3. Using past experience, team computes its velocity … number of
points it can accomplish per scrum period.
Figure 12-24 4. Working with product owner, team selects tasks for the
Summary of Scrum Estimation upcoming scrum period, constrained by its velocity.
Techniques

6 Chris Sims and Hillary Louise Johnson, The Elements of Scrum (Dymaxcon, 2011), pp. 125–133.