Page 199 -

166 part 2 • inforMation requireMents analysis

Need or Opportunity:
Apply shortcut methods for faster checkout.
Story: If the identity of the customer is known and the delivery address matches, speed up the

such as shipping method.
transaction by accepting the credit card on file and the rest of the customer’s preferences
Well Below
Activities: Below Average Average
Coding Above Average Well Above
Testing
Listening
Designing
Resources:
Time
Cost
Quality
Scope

Figure 6.6
User stories can be recorded on
cards. The user story should be Offer options for shipping.
brief enough for an analyst to
determine what systems features Allow the customer to choose a shipping method based on cost.
are needed. Complete the transaction.
Finish the transaction. Ask for credit card confirmation if the shipping address is different
from the customer’s address on file.
As you can easily see, there is no shortage of stories. An agile analyst needs to choose a
few stories, complete the programming, and release the product. Once this is done, more stories
are selected and a new version is released until all the stories are included in the system (or the
analyst and customer agree that a particular story lacks merit or is not pressing and so need not
be included).
An example of a user story as it might appear to an agile developer is shown in Figure 6.6.
On paper cards (or electronically), an analyst might first identify the need or opportunity and
then follow it with a brief story description. The analyst might take the opportunity to begin
thinking broadly about the activities that need to be completed as well as the resources it will
take to finish the project. In this example from the online merchant, the analyst indicates that the
designing activity will take above-average effort, and the time and quality resources are required
to rise above average. Notice that the analyst is not trying to be more precise than currently pos-
sible on this estimate, but it is still a useful exercise.
SCRUM. Another agile approach is named scrum. The word scrum is taken from a starting
position in rugby in which the rugby teams form a huddle and fight for possession of the ball.
Scrum is really about teamwork, similar to what is needed in playing a game of rugby.
Just as rugby teams will come to a game with an overall strategy, development teams begin
a project with a high-level plan that can be changed on the fly as the “game” progresses. Systems
development team members realize that the success of the project is most important, and their
individual success is secondary. The project leader has some, but not much, influence on the
detail. Rather, the tactical game is left up to the team members, just as if they were on the field.
The systems team works within a strict time frame (30 days for development), just as a rugby
team would play in a strict time constraint of a game.
We can describe the components of the scrum methodology as:
1. Product backlog, in which a list is derived from product specifications.
2. Sprint backlog, a dynamically changing list of tasks to be completed in the next sprint.
3. Sprint, a 30-day period in which the development team transforms the backlog into soft-
ware that can be demonstrated.