Scrum an Agile Methodology

Post on 21-Jan-2018

236 views 4 download

transcript

ScrumAn agile methodology

XAMIN Team

Zahra Golmirzaei

IST 2014, Tehran

Content

› SDM definition

› Review traditional SDM

› Agile methodology– Definition

– Type

› Scrum – roles

– Artifacts

– Process

2

SDM

› Software Development Methodology

› A framework that is used to structure, plan, and control the process of developing an information system

3

SDM

› Software Development Methodology

› A framework that is used to structure, plan, and control the process of developing an information system

› How to develop a software?– Just code and fix

4

SDM

› Software Development Methodology

› A framework that is used to structure, plan, and control the process of developing an information system

› How to develop a software?– Just code and fix

› No overhead , Requires little expertise

› No process, QC, Highly risky

5

1950s Code & fix

SDM

› Software Development Methodology

› A framework that is used to structure, plan, and control the process of developing an information system

› How to develop a software?– Design, Code, Test, Maintain

6

1950s Code & fix

1960s Design-code-test-Maintain

SDM

› Software Development Methodology

› A framework that is used to structure, plan, and control the process of developing an information system

› Software Development Life Cycle

7

1950s Code & fix

1960s Design-code-test-Maintain

8

SDM

› Software Development Methodology

› A framework that is used to structure, plan, and control the process of developing an information system

› Software Development Life Cycle– Waterfall

9

1950s Code & fix

1960s Design-code-test-Maintain

1970s Waterfall model

10

Waterfall model

11

Waterfall model

You don’t realize any value until the end of the project

You leave the testing until the end

You don’t seek approval from the stakeholders until late in the day

changes

Takes too long

skipped

12

Waterfall model

SDM

› Software Development Methodology

› A framework that is used to structure, plan, and control the process of developing an information system

13

1950s Code & fix

1960s Design-code-test-Maintain

1970s Waterfall model

1980s Spiral Model

1990sV-model/Rapid applicationdevelopment

2000s Agile methods

SDM- RUP

14

RUP

› Inception: defining the scope and objectives of the project, as

› well as the business case

› Elaboration: capturing the crucial requirements, developingand validating the architecture of the software system, andplanning the remaining phases of the project

› Construction: implementing the system in an iterative andincremental fashion based on the architecture developed inthe

› previous phase

› Transition: testing and releasing the system

15

SDM

16

RUP Waterfall Spiral

SDM

17

RUP Waterfall Spiral

Agile methodology

18

What is agile

› Agile – readiness for motion, nimbleness, activity, dexterity in motion

› Agility– The ability to both create and respond to change in order to profit in a turbulent business environment

– Companies need to determine the amount of agility they need to be competitive

19

Agile method

› The aim of agile methods is to reduce overheads in thesoftware process (e.g. by limiting documentation) and tobe able to respond quickly to changing requirementswithout excessive rework

› Light Weighted methodology

› Small to medium sized teams

› One of the most common methodologies

20

Agile manifesto

21

http://agilemanifesto.org/

http://agilemanifesto.org/iso/pr/

The principles of agile methods

22

Principle Description

Customer involvement Customers should be closely involved throughout the

development process. Their role is provide and prioritize new

system requirements and to evaluate the iterations of the

system.

Incremental delivery The software is developed in increments with the customer

specifying the requirements to be included in each increment.

People not process The skills of the development team should be recognized and

exploited. Team members should be left to develop their own

ways of working without prescriptive processes.

Embrace change Expect the system requirements to change and so design the

system to accommodate these changes.

Maintain simplicity Focus on simplicity in both the software being developed and

in the development process. Wherever possible, actively work

to eliminate complexity from the system.

Agile characteristic

› Iterative

23

Agile characteristic

› Iterative

› Incremental

24

Agile characteristic

25

Agile characteristic

› Iterative

› Incremental

› self organize

26

Agile benefits

› Faster time to market

› Minimize risk (short iteration)

› Reduce overhead

› Agile team

› Better response to customer requirement

27

Agile challenges

› Keep the interest of customers

› Team members

› Prioritizing changes can be difficult where there are multiple stakeholders.

› Maintaining simplicity requires extra work.

28

Agile Methods

› Agile methods:– Scrum

– Extreme Programming (XP)

– Adaptive Software Development (ASD)

– Dynamic System Development Method (DSDM)

– …

› Agile Alliance– A non-profit organization promotes agile development

› http://www.agilealliance.org/

29

Scrum

30

Why Talk About Scrum?

› Popular

› Powerful

› Easy to learn

31

Scrum has been used by:• Microsoft

• Yahoo

• Google

• Amazon

• Electronic Arts

• High Moon Studios

• Lockheed Martin

• Philips

• Siemens

• Nokia

• Capital One

• Intuit

• Intuit

• Nielsen Media

• First American Real Estate

• BMC Software

• Ipswitch

• John Deere

• Lexis Nexis

• Sabre

• Salesforce.com

• Time Warner

• Turner Broadcasting

• Oce

32

Scrum

› SCRUM is an agile, lightweight process for managing and controlling software and product development in rapidly changing environments.

– Iterative, incremental process– Team-based approach– developing systems/ products with rapidly changing requirements

– Controls the chaos of conflicting interest and needs– Improve communication and maximize cooperation– Protecting the team form disruptions and impediments– A way to maximize productivity

33

Requirements Design Code Test

Time

Scrum Overview

Requirements Design Code Test

Time

Rather than doing all of one thing at a time...

Scrum teams do a little of everything all the time

Shippable

Scrum Overview

Scrum Framework

Roles

Product Owner

Scrum Master

Team

Artifacts

Product backlog

Sprint Backlog

Burn Down Charts

Ceremonies

Sprint Planning

Sprint Review

Sprint Retrospective

Daily Scrum Meeting

Scrum Roles

38

Product Owner

› What is the essence of the product owner role?– a product owner should own the product on behalf of the company.

– You can think of the product owner as the individual who champions the product

– who facilitates the product decisions

– and who has the final say about the product,

39

Product Owner

40

Scrum Master

› 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

› A Scrum Master should never be the Product owner

Team

› Typically 7 people (+/- 2)

› Cross-functional

› self-organizing

› Membership should change only between sprints

› Turns the product backlog into increments of potentially shippable functionality

› Show the deliverables to the product owner

Role; The Scrum Team

Scrum Teams are self-organizing and cross-functional. The team model in Scrum is designed to optimize 1. Flexibility2. Creativity3. productivity.

Scrum Team

Scrum Roles

44

Scrum Framework

Roles

Product Owner

Scrum Master

Team

Artifacts

Product backlog

Sprint Backlog

Burn Down Charts

Ceremonies

Sprint Planning

Sprint Review

Sprint Retrospective

Daily Scrum Meeting

Scrum Process

46

Decision level

47

Product vision board

48

Product Roadmap

49

Product Roadmap

50

Product Roadmap

51

Product backlog

52

Product Backlog Item, PBI

A Product Backlog is a list of top-level requirements that are usually associated with a single Project or Product.

Product Backlog

› Is the list of requirements per product.

› Is dynamic and in constantly evolution. (alive document)

› Prioritized by the product owner

– Risk, value, and necessity.

› Reprioritized at the start of each sprint.

› Product Backlogs items are usually stated as user stories.

› Should take around 10% of each sprint to review the product backlog

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 reservation. 3

As a hotel employee, I can run RevPAR reports (revenue-

per-available-room)8

Improve exception handling 8

... 30

... 50

Product backlog

56

Product backlog

57

Product backlog

58

Theme

Epic

User Story

User Story

User Story

Epic

User Story

User Story

PBI

Theme

Epic

User Story

User Story

User Story

Epic

User Story

User Story

PBI

Themes- very top-level requirements or objectives e.g. A new website

Epics – very large user stories e.g. A new website section

Theme

Epic

User Story

User Story

User Story

Epic

User Story

User Story

PBI

Theme

Epic

User Story

User Story

User Story

Epic

User Story

User Story

PBI

User Stories – an Independent, Negotiable, Valuable, Estimatable, Small, Testable (“INVEST”) piece of functionalitywhich are short, simple descriptions of the desired functionality told from perspective of the user

Theme

Epic

User Story

User Story

User Story

Epic

User Story

User Story

Feature

Bug

Technical work

Knowledge acquisition

PBI

User Stories – an Independent, Negotiable, Valuable, Estimatable, Small, Testable (“INVEST”) piece of functionalitywhich are short, simple descriptions of the desired functionality told from perspective of the user

Product Backlog Sample

User story

› User story essentials

› Telling stories about the user experience

› Mapping user stories based on experience– using this useful template:

As a [type of user]

I want to [perform some task]

so that I can [reach some goal]

65

Product Backlog Item, PBI

A Product Backlog is a list of top-level requirements that are usually associated with a single Project or Product.

Sprint backlog

› Consists of the tasks the Team performs to turn Product Backlog items into a “done” increment.

› It is developed during the Sprint Planning Meeting.

› It is all of the work that the Team identifies as necessary to meet the Sprint goal.

› One day or less is a usual size for a Sprint Backlog item that is being worked on.

› Only the Team can change its Sprint Backlog during a Sprint

Tasks Estimate Assignee Sat Sun Mon Tue Wed Thurs

Code the user interface 16 8 4 4

Code the middle tier 50 16 12 10 4

Test the middle tier 40 6 7 9 11 8

Write online help 20 12

Write the food class 36 6 6 6 6 6 6

Add error logging 10 6 3

…. ..

Sprint Burn Down Chart

› Is a graph of the amount of Sprint Backlog work remaining in a Sprint across time in the Sprint

Hours

40

30

20

10

0Mon Tue Wed Thu Fri

50

Sprint Burn Down Chart

72

73

time

74

time

75

time

76

time

Below each activity, or large story are the child stories that make it up

necessity

77

time

necessity

task

sub-tasks or

task details

78

time

optionalit

ynecessary

less

optional

more

optional

first release

second release

third release

Scrum Process

Sprint

1- Sprint Planning Meeting (2-4 Hours)Part One: What will be done this Sprint?Part Two: How will the chosen work get done?

1

2- Daily Scrum Meeting (15 m)What has been accomplished since the last meeting?What will be done before the next meeting?What obstacles are in the way?

2

3 - Sprint Review (1-2 Hours)Release “Done” Backlog

3

4 - Sprint Retro (1-2 Hours)

4

Sprint Planning Meeting

Sprint PlanningMeeting

Product Backlog

Team Capabilities

Business Conditions

Technology

Current Product

Sprint Backlog

Sprint Goal

We should use 5% of our sprint time on this.At most workplaces, 10% of the sprint is time boxed for this meeting.

Daily Scrum

15 minutes

What have you done since the last meeting

What will you do before next meeting

What is in your way

Decisions

Do not digress beyond

answering the three questions

Product owner gives updates

Sprint review meeting tasks

Scrum Master

• Set the Agenda

• Project reporting

• Snapshot of sprint retrospect

• Address the stake holders

Team

• Present the product increment

• Present individual stories

• For every story –demo development, QA and documentation

Product owner

• Evaluate functionality

• Confirm the stories that have fulfilled the DONE criteria

• Include surprises (if any)

Sprint Retrospective

What worked well

What did not go well

Take away

Typical Sprint

Sprint Planning & Retrospective

Sprint work

Sprint Review

Backlog refinement

10%

80%

5%

5%

2 weeks

85

Product Owner Responsibilities

Organize the backlog into incremental releases

Specify objective acceptance criteria for stories

• Communicate Business Goals, Customer Goals, End User Goals

• Coordinate involvement of SMEs, users, and business stakeholders

• Coordinate with other product owners to insure coherence of product and releases

Create and maintain the product backlog

Participate daily

Be available to answer questions and clarify details on user stories

Verify stories are done based on acceptance criteria

Evaluate product at end of Sprint and add or remove stories from backlog as necessary

PO Challenges

Partial PO PO Committee

Proxy PO

Underpowered PO

ProductOwnerHierarchy

Scrum of Scrums / Meta-Scrum

Scrum Master Product OwnerScrum team member

When to use

› requirements are not clearly defined.

› work is delivered in increments

› work is measured and controlled

› productivity is maximized by applying known technologies

› organizations are willing to do anything and everything for a project to succeed

› project is important and no one has confidence that any existing approach will work.

› control and management is Empirical

90

When to avoid

› there isn’t a flexible environment

› corporate culture isn’t conducive to this of development environment

› teams of developers are more than 10. Six is ideal.

› Cost is a major issue

› No management support

› No formal training available

91

Ref

› Mike Cohn, User Stories Applied: For Agile Software Development, 2004

› Mike Cohn , Succeeding with Agile : Software Development Using Scrum, 2009

› Iian Goldstein, Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips, 2013

› Kenneth S. Rubin, Essential Scrum: A Practical Guide to the Most Popular Agile Process, 2012

› Rachel Davies, Liz Sedley, Agile Coaching, 2009

Ref

› http://scrummethodology.com/

› https://www.scrumalliance.org

› https://www.scrum.org/

› http://www.romanpichler.com/blog/

Thanks for your attention

94