Friedrich-Alexander-University of Erlangen-Nuremberg

Agile and Open Source

Software Development 3/15

 Dirk Riehle

 Friedrich-Alexander-University of Erlangen-Nuremberg

Content of This Lecture

Section Content

1 Limits of Lifecycle Model

2 Introduction of Agile Methods

3 Scrum Roles, Practices, Artifacts

4 Scrum's Product Management

5 Scrum's Development Process

Recap Lifecycle Model

 Linear, phase-oriented process model

 Intends to minimize risk through upfront planning

 No iterations, no user feedback, equates activities with phases

analysis design

imple-mentation

start end

time

3.1

An Analogy for the Lifecycle Model

From Extreme Programming Explained

Learning to Drive

Driving is about constantly paying attention,

making a little correction this way, a little correction that way.

This is the paradigm for XP. Stay aware. Adapt. Change.

 Agile methods is the name of a class of process models

 Extreme Programming, SCRUM, DSDM, Adaptive Software Development,

Crystal, Feature-Driven Development, Pragmatic Programming, etc.

 Unified by the recognition of a common philosophical base and joined in their

rejection of the traditional life-cycle model

 Iterative processes are not new, see [Budde 1984] [Floyd

1989]

Agile Methods

3.2

Introduction of Agile Methods

P E R

P E R P E R

... ...

Agile Philosophy and Agile Manifesto

 Core agile method values

 Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation

 Responding to change over following a plan

 Codified (and marketed) as the Agile Manifesto

Scrum and Extreme Programming

Scrum

(mostly as process framework)

Scrum

 A particular agile method, invented around 1993, 1995

 See [Sutherland 1995], [Schwaber 1995]

 A rugby situation requiring intense self-organizing collaboration

Scrum's Roles, Practices, and Artifacts

3.3

Scrum's Roles, Practices, Artifact

Scrum

Roles and Responsibilities

Scrum Role: Product Owner

 The product owner holds overall responsibility for the product

 Focus is on delivering business value through the product  Owns and maintains product backlog and release plan  Defines feature functionality and scope

 Faces internal and external customers, marketing department  Is available to team to answer questions during sprints

 Jointly with development team

 Assesses and determines risk of features  Addresses external supplies to product

Scrum Role: Team and Team Member

 Team responsibilities

 Delivers product matching the agreed-upon requirements  Commits to achieving sprint goals after planning discussion  Is responsible to reaching appropriate development velocity

 Team member responsibilities

 Performs analysis, design, coding, testing, and documentation activities

 Team composition

Scrum Role: Scrum Master (also ScrumMaster)

 Scrum master responsibilities

 Primary goal is to create a self-sustaining process

 Manages process, coaches people, brings forward issues  Protects the team during the sprint from outside interruptions

 The scrum master does not...

 Manage people nor does performance evaluations  Act as the project manager to rest of world

 Please note: scrum master is a role; may also be team

Scrum's Product Management

 Product owner is responsible for product management

 Product owner creates product concept  Product owner maintains product backlog

 Product backlog is a prioritized feature list

 Maintained as list or table in spreadsheet or on wiki

 Does not contain activity descriptions (see planning, sprint backlog)

 Feature (or requirement) describes a user requirement

 Again, no activity, just a description of a user need  Can be functional or non-functional requirements

 Product management runs in parallel to development

3.4

Wahlzeit Product Concept

Wahlzeit Product Concept

 Wahlzeit is a Web 2.0 application that lets users upload phot

get to present their best photos and learn what other users th

 Wahlzeit is used to teach agile methods and open source sof

Software at the University of Erlangen.

Wahlzeit Flowers Product Concept

Wahlzeit Flowers Product Concept

 Wahlzeit Flowers is a web service that lets users upload flow

Users get to present their best flower photos and can discuss users in discussion forums.

 Wahlzeit Flowers provides a high-quality channel for the flow

Requirements Analysis and Feature Description

 Feature description

 Description: Allow user to determine notification interval about recent praise  Acceptance tests: Profile UI allows for configuring notification intervals and

notification agent sends out email according to user specification

 User story

 User story: I'd like to switch on and off notifications as well as enter the

notification interval; I provide the interval in days

 Acceptance tests: Notifications on or off are displayed as a flag; interval is

provided in days as a number >= 1 and < 30

 Use case

 Use case: The user goes to the profile menu; s/he can switch on and off a

boolean flag for notifications; the user can enter a number for the notification interval; finally, the user exits by clicking save

 Acceptance tests: After saving, the flag and notification interval are

Properties of a Good Feature Description

I

ndependent: Features are orthogonal (independent) of each other.

N

egotiable: No feature is cast in stone; can be split or merged.

V

aluable: Every feature should have apparent (economic) value.

E

stimatable: A feature should be clear and specific so the team can estima

S

mall: A feature should be small enough to be implemented in one sprint.

Example Wahlzeit Feature Description

Allow a user to configure praise

notifications for photos. A praise notification is one email listing all photos and their

changes in praise. The email is sent out in regular intervals. The user can switch on and off the notifications, and the user can determine the frequency of such

Scrum's Development Process

 Succession of equal-length sprints (= short iterations)

 Intervention points are during planning and review

 Product owner is always available to answer questions

P = planning

E = engineering (i.e. design and implementation) R = review (or release or retrospective)

P E R P E R P E R ... ... time sprint n+1 sprint n-1 sprint n

1-4 weeks 1-4 weeks 1-4 weeks

3.5

The Significance of (Short) Iterations

 Short iterations lead to focus on high-value features first

 User feedback helps team steer product to meeting needs

right

 Quality feedback helps team deliver high-quality software

 Feedback loop ensures problems and hence risk surfaces

early

 Iterations help recognize and realize new innovative features

 Established well-worn rhythm is sustainable, avoids burnout

 Even with missed deadlines, partial functionality is better than

none

Structure of an Exemplary Sprint day 5 Wednesday day 1 Thursday day 3 Monday day 2 Friday

product backlog development software development

product backlog development software development

product backlog development software development product backlog development

Start and Duration of a Sprint

 Original recommendation: one month for a sprint

 In some application domains, one month sprints are too long  With one-month iterations, you can start on a Monday or the 1st

 Many recommend one week sprints, but they are hard to do

 One-week sprints require well-working team that knows how to scrum  With one-week sprints, start on a Wednesday, not on a Monday

 Two week sprints are realistic, even for beginning teams

 Like with one-week sprints, to start on a Wednesday may be preferable  Alternatively, align with half-month rhythm

Types of Sprints

Regular Sprints

Exploration Sprints

Quantifying Effort with Story Points Point CategoryMeaning 0 No effort 1 Minimal effort 2 Small effort 3 Medium effort 5 Large effort

8 Very large effort

13 Too large effort

 A story point represents

the expected effort for a story

 They are a relative

measure (in contrast to person days)

 Story points typically

bucket stories into effort categories

 Story points are

determined by

3.6

Estimating Effort with Planning Poker

 Planning poker is an estimation technique for user story effort

 Product owner proposes story, development team estimates

effort

 Team acts as expert group (cf. Wideband Delphi method)

 The planning poker process is an iterative negotiation process

1. Product owner suggests story 2. Team members discuss story

3. Each member privately plays card 4. Cards are laid open

Sprint Planning

 Sprint planning serves to create the sprint backlog

 The sprint backlog contains the features to be implemented

 Sprint planning is the first activity of a given sprint

 The product owner provides the prioritized list of features

 Developers play planning poker to assign effort to features

Development Velocity (Speed)

(remember Newtonian physics?)

v = development velocity [story point / sprint]

s = development effort [story point]

Use and Usefulness of Development Velocity

 Over time, an average number of per-sprint story points

emerge

 During demo/review, actual sprint achievements are counted

 Features that have not fully passed acceptance test are not counted

 This average number per sprint is the (team) development

velocity

 The default development velocity is a team metric  Within limits, it can be broken down to a user metric

 Changes to the team and other disruptions destroy its

reliability

 Within limits, if team member availability varies, velocity can be adjusted

 Continued usefulness depends on development practices

Release Planning

 The release plan maps sprints and features into a schedule

 Focuses on overall project/product goals by means of releases  Is a prediction based on current data that is subject to change  By way of derived reports allows for early recognition of problems

 Much of this depends on the type of project or product

Sprint # 1 2 3 15

Start/End21.10.2009 - 27.10.200928.10.2009 - 03.11.200904.11.2009 - 10.11.2009 ... 11.02.2009 - 17.02.2009

Goal Make UI presentableAllow for simple configurationFix-up testing setup

Features 1, 2, 6, 13, 21 9, 12, 14, 18, 27 3, 4, 10, 15 TBD

Effort 13 15 17 TBD

You Can't Manage What You Can't Measure 76 81 10 1 11 5 13 3 69 14 8 ? ? ?

Release Burndown Chart

? ? 8 20 14 18 ? 15 ?

Outlook: Exercises, Next Lecture

 Exercises: planning, estimation

Questions? Feedback!

Announcements http://groups.google.com/group/fau-ws09-auos

Forum https://fsi.informatik.uni-erlangen.de/forum/forum/130

Slides http://osr.informatik.uni-erlangen.de/lehre/ws09/auos