App Design for Business
Topic: Software Engineering
Topic Number: 3

Key topics / learning outcomes
of this lecture
• Software Engineering
• USDP
• Agile and Scrum
2

What is Software Engineering (SE) ?
Wikipedia says:
• "the application of a systematic, disciplined, quantifiable
approach to the development, operation, and
maintenance of software".
• "an engineering discipline that is concerned with all
aspects of software production“
• "the establishment and use of sound engineering
principles in order to economically obtain software that is
reliable and works efficiently on real machines"
3

Software Engineering
• Ian Sommerville
– Software Engineering is concerned with
method, tools and techniques for developing
and managing the process of creating and
evolving software products.
• Oxford English Dictionary
– The professional development, production,
and management of system software.
4

Design and Engineering
• Engineering is
– the application of scientific principles and methods to the
construction of useful structures or machines.
• Design is
– the essence of any engineering discipline
– the creative selection of appropriate principles and
methods to efficiently and effectively transform concept
into reality
• A large part of software development is really about
design in various forms.
5

SE Origins
• The idea and the label are over 40 years old.
– First used at NATO Conference on Software Engineering, Garmisch-
Partenkirchen, Germany, 1968
• "Software Engineering" deliberately chosen as provocative ... an
aspiration.
– "Expressed a need rather than a reality.“
• Serious problems with software development needed to be solved
scientifically and rigourously.
– Ironically many of the same problems remain today...
• By the time of the conference the following year in Rome, the label
"Software Engineering" had stuck fast even if no one knew how to achieve
the goals. – still don’t really know.
6

Present day reality
• The reality is mixed
– Computer Science provides the scientific basis.
– A growing number of software development approaches
are recognised as good engineering practice.
– But many aspects of development are still ad hoc rather
than good scientific or engineering practice.
• Software design is still very difficult.
– Few guiding scientific principles.
– Few universally applicable methods.
– Much poor practice.
– Frequent failures.
7

Key Issues
• Software Engineering principles are particularly relevant to construction
of large systems.
– Involving large numbers of people to manage.
• Mastering complexity.
– Abstraction, information hiding, separation of concerns.
• Continual evolution.
– For improved reliability, fixing errors, incorporation of new features,
improving other desirable qualities.
• Efficiency of development.
– Human-centred tasks are extremely costly.
• Cooperation of people.
– Cannot develop a system in isolated pieces.
• Usability.
8

Properties of Good Software
• Delivers required functionality.
• Maintainable
– can evolve to meeting changes in requirements.
• Dependable
– Robust, reliable, trustworthy.
• Efficient
– Good use of resources: computational, user time,
development time/cost
• Usable
– Usable by the users (or systems) it is designed to
interact with.
9

Scale
• Scaling-up does not work reliably
– too much detail for any one person to deal with
– communication overhead
– effect of changes not obvious
– need for discipline, documentation and
management
10
Note:
It is very important that you keep the
problems of scale and complexity firmly
in mind throughout the course.

Failure...
• Numerous examples of failed or seriously
delayed software development projects.
– Or fail to deliver full functionality within time and
budget.
– E.g., Pensions system, NHS patient records, Taurus
(Stock Exchange), Air Traffic Control
– Disasters: ESA Arianne 5, Patriot Missile System,
Therac-25 radiation therapy machine
– Just about every UK government software
development project...
11

12

By 1995...
13

The Chaos Report 2009
14

The Solution...
• Don't know yet.
– Many unresolved issues.
– Much active research (e.g., SSE group in CS department)
• But, building blocks are:
– Education
– Professionalism
– Standards, Quality Assurance
– Defining sound methodologies and practice
– Application of scientific techniques
– Communication
– Self evaluation
15

The Software Development Process
• Structured set of activities required to develop a
software system, including:
– Requirements Gathering
– Analysis
– Design
– Implementation
– Testing
– Deployment
– Maintenance
• Activities vary depending on organization and type of
system being developed.
• Must be modelled in order to be managed.
16

Requirements Gathering
• Aim: a complete description of the problem and
of the constraints imposed by/on the
environment
• Description may contain:
– Functions of the system
– Future extensions
– Amount of documentation required
– Response time and performance
– Acceptance criteria
• Result: Requirements Specification
17

Analysis
• Aim: Analyse requirements to create a
conceptual model of the software system.
– Data modelling
– Functional modelling and information/control flow
– Behavioural modelling and state
– User interface modelling
• Result: A set of Analysis Models
18
What is a model? A systematic conceptual description of a system, or aspect of a
system, defining its structure and behaviour. Abstraction and simplification are
used to constrain the complexity while retaining the essential information.

Design
• Aim: an implementable model of the software system.
– Sufficient information to allow system to be built.
• Architecture is defined.
– The definition of the global architecture of the system is
essential.
• System is decomposed to components within the
architecture:
– Definition of component interfaces and functionalities
• Design decisions dramatically impact system quality.
– Wrong architecture/design == throw it away.
• You can’t build a tower block on the foundations for a bungalow.
• Result: Detailed Design Documentation
19

Implementation
• Aim: implementation of all design elements.
• Starts from the component specifications
developed during design.
– Interfaces defined in the design should be respected
by the implementation of the component.
• Code should be well documented and easy to
read, flexible, correct, reliable AND fully tested.
• Result: working software.
20

Testing
• Kinds of testing:
– Unit testing: Classes/methods.
– Functional testing: Component implementations against
their interfaces.
– Integration testing: Component integration against system
architecture.
– System testing: validation of the extent to which the
requirements specification is fulfilled.
– Acceptance testing: validation of external behaviour against
user expectations.
– Testing and implementation should run in parallel.
• Result: Fully tested software
21

Deployment
• Package software ready to install on a
computer system.
• Actually installing the software.
• Live testing in real environment.
• Documentation and manuals.
• Training.
• Result: Working software in situ
22

Maintenance
• Aim: keeping the system operational after delivery to the customer.
– Corrective: identification and removal of faults.
– Adaptive: modifications needed to achieve interoperability
with other systems and platforms.
– Perfective: incorporation of new features, improved
performance and other modifications to increase customer
satisfaction.
– Preventive: modifications to mitigate possible degradation
of usability, maintainability, etc.
• The maintenance phase needs to be considered part of the overall development
process.
– Even though the activities within maintenance are
requirements analysis, design, implementation and testing.
– Maintenance is ongoing and expensive.
23

Process Model
• A development process is described in a process model.
– There are many ways of organising development.
– There are many process models described in the literature.
• You need to model the process because:
– when a team writes down a description of its development process, it
forms a common understanding of the activities, resources and
constraints involved in software development..
– creating a process model helps the team find inconsistencies,
redundancies and omissions in the process; as these problems are
noted and corrected the process becomes more effective.
24

Process Model (cont.)
• You need to model the process because (cont.):
– the model reflects the goals of development and shows explicitly how
the product characteristics are to be achieved.
– each development is different, and a process has to be tailored for
different situations, and so the model helps people to understand
these differences.
25

Common Software Lifecycle Models
• Waterfall Development
– Separate and distinct phases of specification and development.
• Prototyping
– Interleaved specification and development.
• Incremental Development
– Development of a system in increments.
• Agile Development
– Continual availability of a fully tested functioning system, developed
with minimal organisational overhead.
• Ad Hoc
26

The Waterfall
• Winston Royce defined the seven-step Waterfall Model in 1970
– (see “Managing the development of large software systems”, proceedings of
IEEE Wescon)
• Widely referenced as the “default process model”.
• Each step is distinctly different, needing to be planned and resourced
differently.
27

But...
• Not all is what is seems...
• Royce actually introduced the Waterfall as a
‘strawman’ that he argued was flawed.
• Constrained iteration is needed to make the process
work.
28

The problem in practice...
• The risk is that iteration is not confined to
successive steps.
• Flaws are not discovered until after significant work
has been done, which then has to be revised or
throw away.
29

Spiral Model (Boehm, 1988)
30

Spiral
• Successive repetitions of the same activities.
• Emphasis on prototyping, well before
operational software built.
• Accommodates successive discovery of
requirements.
• A better reflection of what designers do.
• Accepted as an industry standard model.
– Like the waterfall (ironically).
31

V Model
32
From Wikipedia
Relates each phase of the development cycle to an associated testing phase.
Emphasises different kinds of testing required for each phase.

Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach, often informal
without a defined process.
Select a requirement, analyse/design/implement/test, repeat.
Has advantage of getting a basic version working early and then
developing it step-by-step, from one working version to the next.

Incremental Model
34
deliver 1st
increment
analysis design code test
deliver 2nd
increment
analysis design code test
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be
developed in parallel.
Allows multiple teams to develop same system, providing application structure
can be broken down into relatively independent components/modules.
Needs a well defined architecture and interfaces between parts.

Exploratory Model
35
develop outline
specification
build software
system
use software
system
test adequacy
yes
deliver
no
Incrementally build a system using test/user feedback to guide development.
Find and refine the real requirements by building versions and getting real
users to use them.

Prototyping Model
36
establish outline
specification
develop
prototype
evaluate
prototype
specify
system
design and
implement system
validate system
components
Construct a prototype to determine how to specify and build the real system.
The prototype implementation should not be used as the real system.
"Build the system once to find out what it should really be, throw it away and
build a second system using the knowledge gained."

Agile Development
37
From Wikipedia
eXtreme Programming
Scrum
Crystal Clear
DSDM
and others
A rethink of process and values, to address the problems encountered in
software development.
Lightweight, highly iterative, short iterations, test-driven, focus on value to
customer, frequent releases, ability to cope with change.

No Model
38
Muddle through and hope for the best...

Unified Software Development Process
(USDP or just UP) Jacobsen, 1999
• UP is the development process associated with
the Unified Modeling Language (UML)
– It is use-case driven and risk-confronting
– It is architecture-centric
– It is iterative and incremental
– It is free!
• UP is based on an incremental model.
• Each iteration delivers a part of the system.
• Provides a structural framework for a software
development project.
39

Overall Structure of the UP Lifecycle
40
Business Modeling
Requirements
Analysis & Design
Implementation
Test
Management
Environment
Preliminary
Iteration(s)
Iter.
#1
Phases
Process Workflows
Iterations
Supporting Workflows
Iter.
#2
Iter.
#n
Iter.
#n+1
Iter.
#n+2
Iter.
#m
Iter.
#m+1
Deployment
Configuration Mgmt
Elaboration Inception Construction Transition
Adapted from [Jacobson 1999]

UP Lifecycle Phases and Milestones
Product
Release
41
Inception Elaboration Construction Transition
time
Life-cycle
objectives
Life-cycle
architecture
Initial operational
capability
• Inception Define scope of project and develop business case
• Elaboration Plan project, specify features and baseline architecture
• Construction Build product
• Transition Transition product to its users
Adapted from [Booch 1999]

UP Milestone Acceptance Criteria
• Lifecycle objectives: system scope, key requirements, outline
architecture, risk assessment, business case, feasibility, agreed project
objectives with stakeholders.
• Lifecycle architecture: executable architectural baseline, updated risk
assessment, project plan to support bidding process, business case
verified against plan, continued stakeholder agreement.
• Initial operational capability: product ready for beta test in user
environment.
• Product release: completed beta and acceptance tests, defects fixed
with fixes in the user community.
42

UP Iterations
43
Business Modeling
Requirements
Analysis & Design
Implementation
Test
Management
Environment
Preliminary
Iteration(s)
Iter.
#1
Phases
Process Workflows
Iterations
Supporting Workflows
Iter.
#2
Iter.
#n
Iter.
#n+1
Iter.
#n+2
Iter.
#m
Iter.
#m+1
Deployment
Configuration Mgmt
Elaboration Inception Construction Transition
Adapted from [Jacobson 1999] an iteration in the elaboration phase

UP Phases and Iterations
44
Iteration is key to UPEach iteration is like
a mini-project.Results in an increment.
Inception Elaboration Construction Transition
Arch.
Iteration
... Dev.
Iteration
Dev.
Iteration
... Trans.
Iteration
...
Release Release Release Release Release Release Release Release
Prelim.
Iteration
...
An iteration is a sequence of activities
with an established plan and evaluation
criteria, resulting in an executable release
Adapted from [ Booch 1999]

Iteration Workflows
45
Requirements Analysis Design
Implemen-tation
Testing
UP specifies 5 core workflows
Planning An iteration
Assessment
Specific
Activities
Each iteration may contain all of
the core workflows but with
different emphasis depending on
where the iteration is in the
lifecycle.

Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and
flexible working in large teams, iterations can,
and often do, overlap.
In the example above, Iteration 1 overlaps
significantly with iteration 2.
This requires
careful
planning.

UP Increments
• Each iteration results in the release of various
artefacts, which together are called a
baseline.
• Baselines assist with review and approvals
procedures.
• An increment is actually the difference
between two successive baselines.
47

Inception
48
Requirements
Analysis
Design
Implementation
Test
Inception Elaboration Construction Transition
Preliminary I1 I2 In In+1 In+2 Im Im+1
Iterations

Inception - Goals
• Establish feasibility of the project.
• Create a business case.
• Capture key requirements.
• Scope the system.
• Identify critical risks.
• Create proof of concept prototype.
• Decide whether project is feasible and should
proceed further.
49

Inception - Focus
• Requirements – establish business case, scope
and core requirements.
• Analysis – establish feasibility.
• Design – design proof of concept or technical
prototypes.
• Implementation – build the proof of concept
prototype.
• Test – not generally applicable.
– But do want feedback from stakeholders.
50
N.B. The bars indicate approximately the relative amount of resource needed

Life Cycle Objectives
• Conditions of satisfaction:
– System scope has been defined.
– Key requirements for the system have been
captured. These have been defined and agreed with
the stakeholders.
– An architectural vision exists. This is just a sketch at
this stage.
– A Risk Assessment.
– A Business Case.
– Project feasibility is confirmed.
– The stakeholders agree on the objectives of the
project.
51

Elaboration
52
Requirements
Analysis
Design
Implementation
Test
Inception Elaboration Construction Transition
Preliminary I1 I2 In In+1 In+2 Im Im+1
Iterations

Elaboration - Goals
• Establish an executable architectural baseline.
• Refine Risk Assessment.
• Define quality attributes (defect rates etc.).
• Capture use-cases around 80% of the functional
requirements.
• Create a detailed plan for the construction
phase.
• Formulate a bid which includes resources, time,
equipment, staff and cost.
53

Elaboration - Focus
• Requirements – refine system scope
and requirements.
• Analysis – establish what to build.
• Design – create a stable architecture.
• Implementation – build the architectural
baseline.
• Test – test the architectural baseline.
54

Life Cycle Objectives
• Conditions of satisfaction:
– A resilient, robust executable architectural
baseline has been created.
– The Risk Assessment has been updated.
– A project plan has been created to enable a
realistic bid to be formulated.
– The business case has been verified against the
plan.
– The stakeholders agree to continue.
55

Construction
56
Requirements
Analysis
Design
Implementation
Test
Inception Elaboration Construction Transition
Preliminary I1 I2 In In+1 In+2 Im Im+1
Iterations

Construction - Goals
• Completing use-case identification,
description and realisation.
• Finish analysis, design, implementation and
testing.
• Maintain the integrity of the system
architecture.
• Revise the Risk Assessment.
57

Construction - Focus
• Requirements – uncover any requirements
that had been missed.
• Analysis – finish the analysis model.
• Design – finish the design model.
• Implementation – build the Initial
Operational Capability.
• Test – test the Initial Operational Capability.
58

Life Cycle Objectives
• Conditions of satisfaction:
– The product is ready for beta testing in the user
environment.
59

Transition
60
Requirements
Analysis
Design
Implementation
Test
Inception Elaboration Construction Transition
Preliminary I1 I2 In In+1 In+2 Im Im+1
Iterations

Transition - Goals
• Correct defects.
• Prepare the users site for the new software.
• Tailor the software to operate at the users site.
• Modify software if unforeseen problems arise.
• Create user manuals and other documentation.
• Provide customer consultancy.
• Training.
• Conduct post project review.
61

Transition - Focus
• Requirements – not applicable.
• Analysis – not applicable.
• Design – modify the design if problems
emerge in beta testing.
• Implementation – tailor the software for the
users site and correct problems uncovered in
beta testing.
• Test – beta testing and acceptance testing at
the users site.
62

Agile Methods
• Over the past decade there has been much focus on how to
improve the development process.
• Agile Methods have emerged as a widely used approach:
– Focus on short iterations, teamwork, collaboration, and process
adaptability throughout the life-cycle of the project.
– Minimal planning and overheads (e.g., short, stand-up meetings).
• Relies on skilled, professional approach.
• Minimal != low standards or sloppy work.
– Code-centred approach.
• Code embodies the design.
– Very strong focus on delivering value.
63

Key factors...?
•“Research also indicates that smaller timeframes, with
delivery of software components early and often, will increase
the success rate. Shorter time frames result in an iterative
process ...”
•“...the approach of full requirements definition followed by a
long gap before those requirements are delivered is no longer
appropriate. The high ranking of changing business
requirements suggests that any assumption that there will be
little significant change to requirements once they have been
documented is fundamentally flawed, and that spending
significant time and effort defining them to the maximum
level is inappropriate.”
64

The cost of defects
65

Extreme Programming (Beck 1999)
• A disciplined, iterative, agile approach to software systems
development.
• Some key XP practices
– Test-driven development
– The tests are the system specification
– Releases are as small and frequent as possible
– Pair programming
– Collective code ownership
– Coding standards
– Continuous integration
– Frequent refactoring of code
– Onsite customer is a member of the development team
– 40-hour work week
66

When to use XP
• XP works best when
– Requirements are changing rapidly
– Projects are high-risk with new challenges
– Development can be carried out by small groups
(2-10 developers)
– Automated testing is possible
– Direct customer involvement is possible
Remember that the process must be matched to the problem!
67

Scrum
• A widely used iterative/incremental method
used with agile development.
• The following slides describing Scrum were
created by Mike Cohn of Mountain Goat
Software.
– Creative Commons License
• Widely used by the Open Source movement
68

Scrum in 100 words
• Scrum is an agile process that allows us to
focus on delivering the highest business value in
the shortest time.
• It allows us to rapidly and repeatedly inspect
actual working software (every two weeks to one
month).
• The business sets the priorities. Teams self-organize
to determine the best way to deliver
the highest priority features.
• Every two weeks to a month anyone can see
real working software and decide to release it as
is or continue to enhance it for another sprint.

Scrum origins
• Jeff Sutherland
– Initial scrums at Easel Corp in 1993
– IDX and 500+ people doing Scrum
• Ken Schwaber
– ADM
– Scrum presented at OOPSLA 96 with Sutherland
– Author of three books on Scrum
• Mike Beedle
– Scrum patterns in PLOPD4
• Ken Schwaber and Mike Cohn
– Co-founded Scrum Alliance in 2002, initially
within the Agile Alliance

Scrum has been used by:
• Microsoft
• Yahoo
• Google
• Electronic Arts
• IBM
• Lockheed Martin
• Philips
• Siemens
• Nokia
• Capital One
• BBC
• Intuit
• Nielsen Media
• First American Real Estate
• BMC Software
• Ipswitch
• John Deere
• Lexis Nexis
• Sabre
• Salesforce.com
• Time Warner
• Turner Broadcasting
• Oce

Scrum has been used for:
• Commercial software
• In-house development
• Contract development
• Fixed-price projects
• Financial applications
• ISO 9001-certified
applications
• Embedded systems
• 24x7 systems with
99.999% uptime
requirements
• the Joint Strike Fighter
• Video game development
• FDA-approved, life-critical
systems
• Satellite-control software
• Websites
• Handheld software
• Mobile phones
• Network switching
applications
• ISV applications
• Some of the largest
applications in use

Characteristics
• Self-organizing teams
• Product progresses in a series of 2-4 week
“sprints”
• Requirements are captured as items in a list of
“product backlog”
• No specific engineering practices prescribed
• Uses generative rules to create an agile
environment for delivering projects
• One of the “agile processes”

The Agile Manifesto–a statement
of values
Process and tools
Individuals and
interactions
over
Following a plan
Responding to
change
over
Source: www.agilemanifesto.org
Comprehensive
documentation
Working software over
Contract negotiation
Customer
collaboration
over

Scrum
Sprint goal
Return
Cancel
Gift wrap
Coupons
Gift Cancel
wrap Coupons
Sprint
2-4 weeks
Return
Sprint
backlog
Potentially shippable
product increment
Product
backlog
24 hours

Putting it all together
Image available at
www.mountaingoatsoftware.com/scrum

Sprints
• Scrum projects make progress in a series of
“sprints”
– Analogous to Extreme Programming iterations
• Typical duration is 2–4 weeks or a calendar
month at most
• A constant duration leads to a better rhythm
• Product is designed, coded, and tested during
the sprint

Sequential vs. overlapping
development
Requirements Design Code Test
Rather than doing all
of one thing at a
time... ...Scrum teams do a
little of everything all
the time
Source: “The New New Product Development Game” by Takeuchi and
Nonaka. Harvard Business Review, January 1986.

No changes during a sprint
• Plan sprint durations around how long you
can commit to keeping change out of the
sprint
Change

Scrum framework
Roles
• Product owner
•ScrumMaster
•Team
Ceremonie
s
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artifacts
• Product backlog
•Sprint backlog
•Burndown charts

Scrum framework
Ceremonie
s
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artifacts
• Product backlog
•Sprint backlog
•Burndown charts
Roles
• Product owner
•ScrumMaster
•Team

Product owner
• Define the features of the product
• Decide on release date and content
• Be responsible for the profitability of the
product (ROI)
• Prioritize features according to market value
• Adjust features and priority every iteration, as
needed
• Accept or reject work results

The ScrumMaster
• Represents management to the project
• Responsible for enacting Scrum values and
practices
• Removes impediments
• Ensure that the team is fully functional and
productive
• Enable close cooperation across all roles and
functions
• Shield the team from external interferences

The team
• Typically 5-9 people
• Cross-functional:
– Programmers, testers, user experience designers,
etc.
• Members should be full-time
• May be exceptions (e.g., database administrator)

The team
• Teams are self-organizing
– Ideally, no titles but rarely a possibility
• Membership should change only between
sprints

Roles
Scrum framework
• Product owner
•ScrumMaster
•Team
Ceremonie
s
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artifacts
• Product backlog
•Sprint backlog
•Burndown charts

Sprint planning
meeting
Sprint
prioritization • Analyze and evaluate product
backlog
• Select sprint goal
Sprint planning
• Decide how to achieve sprint
goal (design)
• Create sprint backlog (tasks)
from product backlog items
(user stories / features)
• Estimate sprint backlog in
hours
Sprint
goal
Sprint
backlog
Team
capacity
Product
backlog
Business
conditions
Current
product
Technology

Sprint planning
• Team selects items from the product backlog they
can commit to completing
• Sprint backlog is created
– Tasks are identified and each is estimated (1-16 hours)
– Collaboratively, not done alone by the ScrumMaster
• High-level design is considered
As a vacation
planner, I want to
see photos of the
hotels.
Code the middle tier (8
hours)Code the user interface
(4)Write test fixtures (4)Code
the foo class (6)Update
performance tests (4)

The daily scrum
• Parameters
– Daily
– 15-minutes
– Stand-up
• Not for problem solving
– Whole world is invited
– Only team members, ScrumMaster, product
owner, can talk
• Helps avoid other unnecessary meetings

Everyone answers 3 questions
• These are not status for the ScrumMaster
– They are commitments in front of peers
What did you do yesterday?
1
What will you do today?
2
Is anything in your way?
3

The sprint review
• Team presents what it accomplished during
the sprint
• Typically takes the form of a demo of new
features or underlying architecture
• Informal
– 2-hour prep time rule
– No slides
• Whole team participates
• Invite the world

Sprint retrospective
• Periodically take a look at what is and is not
working
• Typically 15–30 minutes
• Done after every sprint
• Whole team participates
– ScrumMaster
– Product owner
– Team
– Possibly customers and others

Sprint retrospective
• Periodically take a look at what is and is not
working
• Typically 15–30 minutes
• Done after every sprint
• Whole team participates
– ScrumMaster
– Product owner
– Team
– Possibly customers and others

Roles
Scrum framework
• Product owner
•ScrumMaster
•Team
Ceremonie
s
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artifacts
• Product backlog
•Sprint backlog
•Burndown charts

Product backlog
• The requirements
• A list of all desired work on the project
• Ideally expressed such that each item has
value to the users or customers of the product
• Prioritized by the product owner
• Reprioritized at the start of each sprint
This is the
product backlog

A sample product backlog
Backlog item Estimate
Allow a guest to make a reservation 3
As a guest, I want to cancel a reservation. 5
As a guest, I want to change the dates of a
3
reservation.
As a hotel employee, I can run RevPAR
reports (revenue-per-available-room)
8
Improve exception handling 8
... 30
... 50

The sprint goal
• A short statement of what the work will be
focused on during the sprint
Database Application
Life Sciences
Support features necessary for
population genetics studies.
Financial services
Support more technical indicators
than company ABC with real-time,
streaming data.
Make the application run on SQL
Server in addition to Oracle.

Managing the sprint backlog
• Individuals sign up for work of their own choosing
– Work is never assigned
• Estimated work remaining is updated daily
• Any team member can add, delete or change the sprint
backlog
• Work for the sprint emerges
• If work is unclear, define a sprint backlog item with a
larger amount of time and break it down later
• Update work remaining as more becomes known

A sprint backlog
Tasks
Code the user interface
Code the middle tier
Test the middle tier
Write online help
Write the foo class
Mon
8
16
8
12
8
Tues
4
12
16
8
Wed Thur
4
11
8
4
Fri
8
8
Add error logging
8
10
16
8
8

A sprint burndown chart
Hours

Code the user interface
Code the middle tier
Test the middle tier
Write online help
Hours
Tasks
40
30
20
10
0
Mon
8
16
8
12
Tues Wed Thur Fri
4
12
16
8
10
7
16 11
8
Mon Tue Wed Thu Fri
50

Scalability
• Typical individual team is 7 ± 2 people
– Scalability comes from teams of teams
• Factors in scaling
– Type of application
– Team size
– Team dispersion
– Project duration
• Scrum has been used on multiple 500+ person
projects

Scaling through the Scrum of
scrums

Scrum of scrums of scrums

A Scrum reading list
• Agile and Iterative Development: A Manager’s Guide by Craig
Larman
• Agile Estimating and Planning by Mike Cohn
• Agile Project Management with Scrum by Ken Schwaber
• Agile Retrospectives by Esther Derby and Diana Larsen
• Agile Software Development Ecosystems by Jim Highsmith
• Agile Software Development with Scrum by Ken Schwaber and
Mike Beedle
• Scrum and The Enterprise by Ken Schwaber
• User Stories Applied for Agile Software Development by Mike Cohn
• Lots of weekly articles at www.scrumalliance.org

Essential work for next week
• Please consult the OLE for details of:
– Essential readings*
– Seminar/workshop preparation work*
– Recommended further readings
– Any additional learning
* Essential readings and preparation work must always be completed in time
for the next session
106

End of presentation
© Pearson College 2013