Software Engineering

Agile Software Engineering:

Agile methods, Scrum, and
Extreme Programming
1102SE03
MBA, IM, NTPU (M5010) (Spring 2022)
Wed 2, 3, 4 (9:10-12:00) (B8F40)

Min-Yuh Day, Ph.D, https://meet.google.com/

ish-gzmy-pmo

Associate Professor
Institute of Information Management, National Taipei University
https://web.ntpu.edu.tw/~myday
1
2022-03-09
 Syllabus
Week Date Subject/Topics
1 2022/02/23 Introduction to Software Engineering
2 2022/03/02 Software Products and Project Management:
Software product management and prototyping
3 2022/03/09 Agile Software Engineering:
Agile methods, Scrum, and Extreme Programming
4 2022/03/16 Features, Scenarios, and Stories
5 2022/03/23 Case Study on Software Engineering I
6 2022/03/30 Software Architecture: Architectural design,
System decomposition, and Distribution architecture
2
 Syllabus
Week Date Subject/Topics
7 2022/04/06 Make-up holiday (No Classes)
8 2022/04/13 Midterm Project Report
9 2022/04/20 Cloud-Based Software: Virtualization and containers,
Everything as a service, Software as a service
10 2022/04/27 Cloud Computing and Cloud Software Architecture
11 2022/05/04 Microservices Architecture, RESTful services,
Service deployment
12 2022/05/11 Industry Practices of Software Engineering

3
 Syllabus
Week Date Subject/Topics
13 2022/05/18 Case Study on Software Engineering II
14 2022/05/25 Security and Privacy; Reliable Programming;
Testing: Test-driven development, and Code reviews;
DevOps and Code Management: DevOps automation
15 2022/06/01 Final Project Report I
16 2022/06/08 Final Project Report II
17 2022/06/15 Self-learning
18 2022/06/22 Self-learning

4
 Agile
Software
Engineering
5
 Software Engineering
and
Project Management

Analyze Design Build Test Deliver

Requirements System and Implementation Integration Operation
definition Software and and and
design unit testing system testing maintenance

Project Management

6
 Information Management (MIS)
Information Systems

Organizations Technology

Information
Systems

Management

Source: Kenneth C. Laudon & Jane P. Laudon (2014), Management Information Systems: Managing the Digital Firm, Thirteenth Edition, Pearson. 7
 Fundamental MIS Concepts
Business
Challenges

Management

Information Business
Organization
System Solutions

Technology

Source: Kenneth C. Laudon & Jane P. Laudon (2014), Management Information Systems: Managing the Digital Firm, Thirteenth Edition, Pearson. 8
Project-based software engineering
CUSTOMER

Problem

generates helps-with

implemented-by
1 Requirements Software

CUSTOMER and DEVELOPER

DEVELOPER 9
Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson.
Product software engineering
DEVELOPER

1 Opportunity

inspires realizes

implemented-by
Product
Software
features

DEVELOPER DEVELOPER
Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 10
 Software execution models

Stand-alone execution Hybrid execution Software as a service

User’s computer User’s computer User’s computer

User interface User interface

Product functionality Partial functionality User interface
(browser or app)
User data User data

Additional functionality
Product updates User data backups Product functionality
User data
Product updates

Vendor’s servers Vendor’s servers Vendor’s servers

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson.
Product management concerns
Business
needs

Product
manager

Technology Customer
constraints experience

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 12
 Technical interactions of
product managers
Product
vision
management
Product User stories
backlog and
management scenarios
Product
manager
Acceptance Customer
testing testing

User
interface
design
Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 13
Software Development Life Cycle (SDLC)
The waterfall model
Requirements
definition

System and
Software design

Implementation
and unit testing

Integration and
system testing

Operation and
maintenance

Source: Ian Sommerville (2015), Software Engineering, 10th Edition, Pearson. 14

 Plan-based and Agile development
Plan-based development

Requirements Requirements Design and

engineering specification implementation

Requirements change requests

Agile development
Requirements Design and
engineering implementation

Source: Ian Sommerville (2015), Software Engineering, 10th Edition, Pearson. 15

The Continuum of Life Cycles

High
Incremental Agile

Frequency of Delivery

Predictive Iterative
Low

Low High
Degree of Change
Source: Project Management Institute (2017), Agile Practice Guide, Project Management Institute 16
 Predictive Life Cycle

Analyze Design Build Test Deliver

Source: Project Management Institute (2017), Agile Practice Guide, Project Management Institute 17
 Iterative Life Cycle

Prototype Refine

Analyze Build
Analyze Deliver
Design Test

Source: Project Management Institute (2017), Agile Practice Guide, Project Management Institute 18
 A Life Cycle of
Varying-Sized Increments

Analyze Analyze Analyze

Design Design Design
Build Build Build
Test Test Test
Deliver Deliver Deliver

Source: Project Management Institute (2017), Agile Practice Guide, Project Management Institute 19
 Iteration-Based and Flow-Based
Agile Life Cycles
Iteration-Based Agile

Requirements Requirements Requirements Requirements Requirements Requirements

Analysis Analysis Analysis Analysis Repeat Analysis Analysis
Design Design Design Design as needed Design Design
Build Build Build Build … Build Build
Test Test Test Test Test Test

Flow-Based Agile
Requirements Requirements Requirements Requirements Requirements
Analysis Analysis Analysis Analysis Analysis
Design Design Design Design Design
Repeat
Build Build Build Build Build
as needed
Test Test Test Test Test
…
the number of the number of the number of the number of the number of
features in the features in features in the WIP features in the features in the WIP
WIP limit the WIP limit limit WIP limit limit

Source: Project Management Institute (2017), Agile Practice Guide, Project Management Institute 20
 From personas to features
1
Personas A way of representing users

inspire
Natural language descriptions of a user
2 interacting with a software product

Scenarios are-developed-into
3
inspire Stories Natural language
descriptions of
4 something that is
needed or wanted
Features define by users

Fragments of product functionality

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 21
Multi-tier client-server architecture

Client 1

Client 2
Web Application Database
Server Server Server
Client 3

Client …

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 22
 Service-oriented Architecture
Client 1 S1

S2
Client 2
S3
Web Service
Server gateway S4
Client 3
S5

S6
Client …
Services
Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 23
 VM Container
Virtual Virtual User 1 User 2
web server mail server Container 1 Container 2

Server Server Application Application

software software software software

Guest Guest Server Server

OS OS software software

Hypervisor Container manager

Host OS Host OS

Server Hardware Server Hardware

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 24
 Everything as a service
Photo Software as a service Logistics
editing (SaaS) management

Cloud Database
Platform as a service
management Software
(PaaS) development
Monitoring

Storage Infrastructure as a service Computing

Network (IaaS) Virtualization

Cloud data center

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 25
 Software as a service
Software
customers

Software Software services

provider

Cloud
provider Cloud Infrastructure

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 26
 Microservices architecture –
key design questions
What are the
microservices that
make up the system?

How should
How should data
microservices
be distributed and
communicate with
shared? Microservices each other?
architecture
design
How should the How should
microservices in service failure be
the system be detected, reported
coordinated? and managed?
Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 27
 Types of security threat
An attacker attempts to An attacker attempts
deny access to the system to damage the
for legitimate users system or its data

Availability Integrity
threats SOFTWARE threats
PRODUCT
PROGRAM
Distributed denial of Virus
service (DDoS) attack DATA
Ransomware
Data theft

Confidentiality
threats
An attacker tries to gain
access to private information
held by the system
Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 28
Software product quality attributes
1 2
Reliability Availability

7 3
Security Software Resilience
product
quality
6 attributes 4
Usability 5 Maintainability

Responsiveness

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 29
 A refactoring process

1 2
Start Identify
Identify code
refactoring
‘smell’
strategy

4 3
Make small
Run automated
improvement until
code tests
strategy completed

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 30
 Functional testing
Start

1 Unit
Testing

4 2
Release Feature
Testing Testing

3
System
Testing
Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 31
 Test-driven development (TDD)
1
Start Identify new
functionality
2
Identify partial implementation
of functionality

3
Write code stub
Functionality Functionality that will fail test
complete incomplete
4 Run all
automated test
7
Refactor code 5
if required Implement code that should
cause failing test to pass
Test failure
6 Run all
All tests pass automated test
Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 32
 DevOps

Development

Deployment Support

Multi-skilled DevOps team

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 33
Code management and DevOps
DevOps automation
Continuous Continuous Continuous Infrastructure
integration deployment delivery as code

Code management system

Branching and merging
Recover Save and
Code
version retrieve
information repository versions
Transfer code to/from developer’s filestore

DevOps measurement
Data Data Report
collection analysis generation

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 34
Agile
35
 Agile software engineering
• Software products must be brought to market quickly so
rapid software development and delivery is essential.
• Virtually all software products are now developed using an
agile approach.
• Agile software engineering focuses on delivering
functionality quickly,
responding to changing product specifications and
minimizing development overheads.

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 36
 Agile Manifesto Values, Principles,
and Common Practices

Agile 4 12
Mindset Practices
Values Principles

Source: Project Management Institute (2017), Agile Practice Guide, Project Management Institute 37
Agile is a Blanket Term for
Many Approaches
Lean
Agile
Kanban ScrumBan
Crystal
Scrum AUP
XP FDD
DSDM

Source: Project Management Institute (2017), Agile Practice Guide, Project Management Institute 38
 Agile Manifesto and Mindset

Agile is a mindset defined by 4 values,

guided by 12 principles, and
manifested through many different
practices.

Agile practitioners select practices

based on their needs.
Source: Project Management Institute (2017), Agile Practice Guide, Project Management Institute 39
 4
Agile Values
40
 The Four Values of
the Agile Manifesto
(Manifesto for Agile Software Development, 2001)
We are uncovering better ways of developing software by doing it
and helping others do it. Through this work we have come to value:
1. individuals and interactions over processes and tools
2. working software over comprehensive documentation
3. customer collaboration over contract negotiation
4. responding to change over following a plan
That is, while there is value in the items on the right, we value the
items on the left more.

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 41
 12
Agile Principles
42
 The Twelve Principles
Behind the Agile Manifesto
1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the
project.
5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within
a development team is face-to-face conversation.
Source: Project Management Institute (2017), Agile Practice Guide, Project Management Institute 43
 The Twelve Principles
Behind the Agile Manifesto
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements, and designs emerge from self-organizing
teams.
12. At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.

Source: Project Management Institute (2017), Agile Practice Guide, Project Management Institute 44
 Agile Development Principles
• Involve the customer
Involve customers closely with the software development team. Their role is to
provide and prioritize new system requirements and to evaluate each
increment of the system.

• Embrace change
Expect the features of the product and the details of these features to change
as the development team and the product manager learn more about it. Adapt
the software to cope with changes as they are made.

• Develop and deliver incrementally

Always develop software products in increments. Test and evaluate each
increment as it is developed and feed back required changes to the
development team.
Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 45
 Agile Development Principles
• Maintain simplicity
Focus on simplicity in both the software being developed and in
the development process. Wherever possible, do what you can
to eliminate complexity from the system.
• Focus on people, not things
Trust the development team and do not expect everyone to
always do the development process in the same way. Team
members should be left to develop their own ways of working
without being limited by prescriptive software processes.

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 46
 12
Project
Management
Principles
47
 Project Management Body of Knowledge
(PMBOK Guide) PMBOK v6 vs. PMBOK v7
PMBOK Guide v6 PMBOK Guide v7
Project Management Body of Knowledge:
• Introduction The Standard for Project Management :
• Project Environment • Introduction
• Role of the Project Manager • System for Value Delivery
• 10 Knowledge Areas • 12 Project Management Principles:
• Integration
• Scope • 1. Stewardship, 2. Team
• Schedule • 3. Stakeholders, 4. Value
• Cost • 5. Systems Thinking, 5. Leadership
• Quality • 7. Tailoring, 8. Quality
• Resources • 9. Complexity, 10, Risk
• Communications
• Risk • 11. Adaptability and Resiliency
• Procurement • 12. Change
• Stakeholders

The Standard for Project Management Project Management Body of Knowledge:

(5 Process Groups): • 8 Project Performance Domains:
• Initiating • 1. Stakeholders, 2. Team,
• 3. Development approach and Life Cycle
• Planning • 4. Planning, 5. Project Work, 6. Delivery,
• Executing • 7. Measurement, 8. Uncertainty
• Monitoring and Controlling • Tailoring
• Closing • Models, Methods, and Artifacts
Source: Project Management Institute (2021), A Guide to the Project Management Body of Knowledge (PMBOK Guide) –
Seventh Edition and The Standard for Project Management, PMI 48
 Project Management Knowledge Areas
(PMBOK v6)

1. Project Integration Management

2. Project Scope Management
3. Project Schedule Management
4. Project Cost Management
5. Project Quality Management
6. Project Resource Management
7. Project Communications Management
8. Project Risk Management
9. Project Procurement Management
10. Project Stakeholder Management
Source: Project Management Institute (2017), A Guide to the Project Management Body of Knowledge (PMBOK Guide), Sixth Edition, PMI 49
 Project Management Process Groups
(PMBOK v6)

1. Initiating Process Group

2. Planning Process Group
3. Executing Process Group
4. Monitoring and Controlling Process Group
5. Closing Process Group

Source: Project Management Institute (2017), A Guide to the Project Management Body of Knowledge (PMBOK Guide), Sixth Edition, PMI 50
 Project Management 12 Principles
(PMBOK v7)
1. Stewardship
2. Team
3. Stakeholders
4. Value
5. Systems Thinking
6. Leadership
7. Tailoring
8. Quality
9. Complexity
10. Risk
11. Adaptability and Resiliency
12. Change

Source: Project Management Institute (2021), A Guide to the Project Management Body of Knowledge (PMBOK Guide) –
Seventh Edition and The Standard for Project Management, PMI 51
 Project Management
8 Project Performance Domains
(PMBOK v7)

1. Stakeholders
2. Team
3. Development Approach and Life Cycle
4. Planning
5. Project Work
6. Delivery
7. Measurement
8. Uncertainty
Source: Project Management Institute (2021), A Guide to the Project Management Body of Knowledge (PMBOK Guide) –
Seventh Edition and The Standard for Project Management, PMI 52
 Agile software engineering

• A large number of ‘agile methods’ have been developed.

• There is no ‘best’ agile method or technique.
• It depends on who is using the technique, the development team and
the type of product being developed

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 53
 Agile methods
• Plan-driven development evolved to support the engineering of large, long-
lifetime systems
• This approach is based on controlled and rigorous software development
processes that include detailed project planning, requirements specification
and analysis and system modelling.
• However, plan-driven development involves significant overheads and
documentation and it does not support the rapid development and delivery
of software.
• Agile methods were developed in the 1990s to address this problem.
• These methods focus on the software rather than its documentation,
develop software in a series of increments and aim to reduce process
bureaucracy as much as possible.

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 54
 Incremental development
• All agile methods are based around
incremental development and delivery.
• Product development focuses on the software features, where a feature
does something for the software user.
• With incremental development, you start by prioritizing the features so that
the most important features are implemented first.
• You only define the details of the feature being implemented in an
increment.
• That feature is then implemented and delivered.
• Users or surrogate users can try it out and provide feedback to the
development team. You then go on to define and implement the next
feature of the system.

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 55
 Incremental development
1
Product feature list Choose features to
be included
If all features are in increment
complete, deliver 2
5
system release Refine features
Deliver system
increment descriptions

4 3
Integrate feature Implement and
into system test feature

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 56
 Incremental development activities
1. Choose features to be included in an increment
Using the list of features in the planned product, select those features that can be implemented in
the next product increment.

2. Refine feature descriptions

Add detail to the feature descriptions so that the team have a common understanding of each
feature and there is sufficient detail to begin implementation.

3. Implement and test

Implement the feature and develop automated tests for that feature that show that its behaviour is
consistent with its description.

4. Integrate feature and test

Integrate the developed feature with the existing system and test it to check that it works in
conjunction with other features.

5. Deliver system increment

Deliver the system increment to the customer or product manager for checking and comments. If
enough features have been implemented, release a version of the system for customer use.
Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 57
 Extreme programming
• The most influential work that has changed software development
culture was the development of Extreme Programming (XP).
• The name was coined by Kent Beck in 1998 because the approach
was developed by pushing recognized good practice, such as
iterative development, to ‘extreme’ levels.
• Extreme programming focused on 12 new development techniques
that were geared to rapid, incremental software development,
change and delivery.
• Some of these techniques are now widely used; others have been
less popular.

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 58
Extreme Programming Practices
Test-first
development
Continuous
Refactoring
integration

Incremental
planning Small
Extreme releases
Programming
Collective (XP) Simple
ownership
design

Pair On-site
programming customer
Sustainable
pace
Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 59
 Widely adopted XP practices
• Incremental planning/user stories
• There is no ‘grand plan’ for the system. Instead, what needs to be
implemented (the requirements) in each increment are established in
discussions with a customer representative.
• The requirements are written as user stories.
• The stories to be included in a release are determined by the time
available and their relative priority.

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 60
 Widely adopted XP practices
• Small releases
• The minimal useful set of functionality that provides business value is
developed first.
• Releases of the system are frequent and incrementally add
functionality to the previous release.

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 61
 Widely adopted XP practices
• Test-driven development
• Instead of writing code then tests for that code, developers
write the tests first.
• This helps clarify what the code should actually do and that
there is always a ‘tested’ version of the code available.
• An automated unit test framework is used to run the tests after
every change.
• New code should not ‘break’ code that has already been
implemented.

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 62
 Widely adopted XP practices
• Continuous integration
• As soon as the work on a task is complete, it is integrated into the
whole system and a new version of the system is created.
• All unit tests from all developers are run automatically and must be
successful before the new version of the system is accepted.

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 63
 Widely adopted XP practices
• Refactoring
• Refactoring means improving the structure, readability, efficiency and
security of a program.
• All developers are expected to refactor the code as soon as potential
code improvements are found.
• This keeps the code simple and maintainable.

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 64
 Widely adopted XP practices
• Incremental planning/user stories
• There is no ‘grand plan’ for the system. Instead, what needs to be
implemented (the requirements) in each increment are established in
discussions with a customer representative.
• The requirements are written as user stories.
• The stories to be included in a release are determined by the time
available and their relative priority.

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 65
 Scrum
• Software company managers need information that will help them
understand how much it costs to develop a software product, how
long it will take and when the product can be brought to market.
• Plan-driven development provides this information through long-term
development plans that identify deliverables - items the team will
deliver and when these will be delivered.
• Plans always change so anything apart from short-term plans are
unreliable.
• Scrum is an agile method that provides a framework for agile project
organization and planning. It does not mandate any specific technical
practices.

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 66
 Scrum Terminology
• Scrum
A daily team meeting where progress is reviewed and
work to be done that day as discussed and agreed.
• Sprint
A short period, typically two to four weeks, when a
product increment is developed.
• ScrumMaster
A team coach who guides the team in the effective use of
Scrum.

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 67
 Scrum Terminology
• Product
The software product that is being developed by the Scrum
team.
• Product owner
A team member who is responsible for identifying product
features and attributes. They review work done and help to
test the product.
• Product backlog
A to-do list of items such as bugs, features and product
improvements that the Scrum team have not yet completed.
Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 68
 Scrum Terminology
• Development team
A small self-organising team of five to eight people who
are responsible for developing the product.
• Potentially shippable product increment
The output of a sprint which should be of high enough
quality to be deployed for customer use.
• Velocity
An estimate of how much work a team can do in a single
sprint.

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 69
 Key roles in Scrum
• The Product Owner is responsible for ensuring that the development
team are always focused on the product they are building rather than
diverted into technically interesting but less relevant work.
• In product development, the product manager should normally take on
the Product Owner role.
• The ScrumMaster is a Scrum expert whose job is to guide the team in
the effective use of the Scrum method. The developers of Scrum
emphasize that the ScrumMaster is not a conventional project
manager but is a coach for the team. They have authority within the
team on how Scrum is used.
• In many companies that use Scrum, the ScrumMaster also has some
project management responsibilities.

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 70
 Scrum and sprints
• In Scrum, software is developed in sprints, which are fixed-length
periods (2 - 4 weeks) in which software features are developed
and delivered.
• During a sprint, the team has daily meetings (Scrums) to review
progress and to update the list of work items that are incomplete.
• Sprints should produce a ‘shippable product increment’. This
means that the developed software should be complete and
ready to deploy.

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 71
 Scrum cycles
Start 1 Review product
backlog

Select items
to implement
Review Product
sprint backlog
Plan
sprint

Shippable sprint
product increment

Test Sprint
software
Scrum
backlog

Develop
software
Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 72
 Key Scrum practices
• Product backlog
This is a to-do list of items to be implemented that is
reviewed and updated before each sprint.
• Timeboxed sprints
Fixed-time (2-4 week) periods in which items from the
product backlog are implemented,
• Self-organizing teams
Self-organizing teams make their own decisions and work by
discussing issues and making decisions by consensus.

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 73
 Product backlogs
• The product backlog is a list of what needs to be done to complete
the development of the product.
• The items on this list are called product backlog items (PBIs).
• The product backlog may include a variety of different items such
as product features to be implemented, user requests, essential
development activities and desirable engineering improvements.
• The product backlog should always be prioritized so that the items
that be implemented first are at the top of the list.

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 74
 Examples of
Product Backlog Items (PBIs)
1. As a teacher, I want to be able to configure the group of tools that are
available to individual classes. (feature)
2. As a parent, I want to be able to view my children’s work and the
assessments made by their teachers. (feature)
3. As a teacher of young children, I want a pictorial interface for children with
limited reading ability. (user request)
4. Establish criteria for the assessment of open source software that might be
used as a basis for parts of this system. (development activity)
5. Refactor user interface code to improve understandability and performance.
(engineering improvement)
6. Implement encryption for all personal user data. (engineering improvement)

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 75
 Product backlog item states
• Ready for consideration
These are high-level ideas and feature descriptions that will be
considered for inclusion in the product. They are tentative so may
radically change or may not be included in the final product.
• Ready for refinement
The team has agreed that this is an important item that should be
implemented as part of the current development. There is a reasonably
clear definition of what is required. However, work is needed to
understand and refine the item.
• Ready for implementation
The PBI has enough detail for the team to estimate the effort involved
and to implement the item. Dependencies on other items have been
identified.
Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 76
 Product backlog activities
REVISED
PRODUCT BACKLOG PRODUCT BACKLOG

PBI 1.1
PBI 1 Refinement
PBI 1.2
PBI 2
Estimation PBI 2E
PBI 3
PBI 3E
PBI 4 Prioritization PBI 4

PBI 5 PBI 5
Creation
PBI 6

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 77
 Sprint activities

Sprint Sprint Sprint

planning backlog review

Sprint
execution

Sprint
Integration backlog
Scrum

Develop
software
Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 78
Managing External Interactions
External
interactions

Team-focused Product-focused
external interactions external interactions

ScrumMaster Product owner

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 79
Project Management Responsibilities
Budget
Reporting Schedule
Risks
Problems
Progress

Project
Management
Administration People

Finance Vacations
Compliance Absence
Procurement Work quality
Liaison Reviewing
Hiring
Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 80
 Summary
• The best way to develop software products is to use agile
software engineering methods that are geared to rapid product
development and delivery.
• Agile methods are based around iterative development and the
minimization of overheads during the development process.
• Extreme programming (XP) is an influential agile method that
introduced agile development practices such as user stories, test-
first development and continuous integration. These are now
mainstream software development activities.

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 81
 Summary
• Scrum is an agile method that focuses on agile planning and
management. Unlike XP, it does not define the engineering
practices to be used. The development team may use any technical
practices that they believe are appropriate for the product being
developed.
• In Scrum, work to be done is maintained in a product backlog – a
list of work items to be completed. Each increment of the software
implements some of the work items from the product backlog.

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 82
 Summary
• Sprints are fixed-time activities (usually 2–4 weeks) where a product
increment is developed. Increments should be ‘potentially
shippable’ i.e. they should not need further work before they are
delivered.
• A self-organizing team is a development team that organizes the
work to be done by discussion and agreement amongst team
members.
• Scrum practices such as the product backlog, sprints and self-
organizing teams can be used in any agile development process,
even if other aspects of Scrum are not used.

Source: Ian Sommerville (2019), Engineering Software Products: An Introduction to Modern Software Engineering, Pearson. 83
 References
• Ian Sommerville (2019), Engineering Software Products: An Introduction to
Modern Software Engineering, Pearson.
• Ian Sommerville (2015), Software Engineering, 10th Edition, Pearson.
• Titus Winters, Tom Manshreck, and Hyrum Wright (2020), Software Engineering at
Google: Lessons Learned from Programming Over Time, O'Reilly Media.
• Project Management Institute (2021), A Guide to the Project Management Body of
Knowledge (PMBOK Guide) – Seventh Edition and The Standard for Project
Management, PMI.
• Project Management Institute (2017), A Guide to the Project Management Body of
Knowledge (PMBOK Guide), Sixth Edition, Project Management Institute.
• Project Management Institute (2017), Agile Practice Guide, Project Management
Institute.

84