Top Banner
Scrum Workshop Alex Rosales September 7 th , 2012
104

Scrum workshop - September 7, 2012

Jan 28, 2015

Download

Technology

MrAlexRosales

Scrum Workshop presentation done by Alex Rosales on Septembe 7, 2012 - Quang Trung Software City, HCMC, Vietnam
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Scrum workshop - September 7, 2012

Scrum Workshop

Alex RosalesSeptember 7th, 2012

Page 2: Scrum workshop - September 7, 2012

Switch off your phone at all times

or

Page 3: Scrum workshop - September 7, 2012

Introduction to

Agile

Page 4: Scrum workshop - September 7, 2012

1 What is Agile?

2 Why Agile?

3 How Long to Learn?

Page 5: Scrum workshop - September 7, 2012

“To be competitive, organizations need to drive innovation in every part of

their business”

Page 6: Scrum workshop - September 7, 2012

What is Agile?

Page 7: Scrum workshop - September 7, 2012

It is a mindset for effectively completing

projects.

Page 8: Scrum workshop - September 7, 2012

DUH !

Page 9: Scrum workshop - September 7, 2012

Common Sense

Common Practice

Yes

No

Page 10: Scrum workshop - September 7, 2012

Agile Methods

XP SCRUM Crystal

FDD Lean DSDM

Page 11: Scrum workshop - September 7, 2012

Common Characteristics

Iterative Development

Cross-Functional & Self-Organized Team

Face-to-Face Communication vs. Documents

Open Office vs. Cubicles

Page 12: Scrum workshop - September 7, 2012

Why Agile?

Page 13: Scrum workshop - September 7, 2012

Traditional Approach to managing Software

Development Projects failing far too often

Page 14: Scrum workshop - September 7, 2012

Why it Fails?

Page 15: Scrum workshop - September 7, 2012

Traditional Methodology is too heavy and bureaucratic

Page 16: Scrum workshop - September 7, 2012

Difficult to remain competitive

Page 17: Scrum workshop - September 7, 2012

Example of Failures

Page 18: Scrum workshop - September 7, 2012

Cloud Notes Inc.Anytime, Anywhere, post it!

Page 19: Scrum workshop - September 7, 2012

Two major reasons for failure:

Disappointing features

Poor Interfaces cause failure

Page 20: Scrum workshop - September 7, 2012

What are we learning here?

Page 21: Scrum workshop - September 7, 2012

Success is not just functionality anymore

Page 22: Scrum workshop - September 7, 2012

Example of Success

Page 23: Scrum workshop - September 7, 2012

How many features?

Page 24: Scrum workshop - September 7, 2012

1

Page 25: Scrum workshop - September 7, 2012

Features are not that important

What are we learning?

Page 26: Scrum workshop - September 7, 2012

What’s more important?

Usability

User Experience

Page 27: Scrum workshop - September 7, 2012

Why use Agile Methods?

Page 28: Scrum workshop - September 7, 2012

Incremental Approach breaks complex projects

down into simple mini-projects

Page 29: Scrum workshop - September 7, 2012

Accommodates Change Easily

Page 30: Scrum workshop - September 7, 2012

Improve ROI

Page 31: Scrum workshop - September 7, 2012

Able to deliver quicklyChange oftenMitigate riskInvolve customerUltimate freedomUltimate responsibility

Page 32: Scrum workshop - September 7, 2012

Increase Business ValueLower Development RiskHigher QualityLess DefectsEmployee EngagementTrust in People…

Page 33: Scrum workshop - September 7, 2012

How Long to Learn?

Page 34: Scrum workshop - September 7, 2012

Few hours to learn,Life time to master

Page 35: Scrum workshop - September 7, 2012

Conclusion:

Page 36: Scrum workshop - September 7, 2012

Agile Approach

Adaptive, empirical process• Small repeating cycles• Short-term planning with constant feedback, inspection and

adaptation

Scope

Develop

DefineEvaluate

Page 37: Scrum workshop - September 7, 2012

Agile Manifesto

Driven by technical forces, the Agile Manifesto was

created on February 2001

Page 38: Scrum workshop - September 7, 2012

Do you know the most common Agile Method?

Page 39: Scrum workshop - September 7, 2012

Team that get it right,1 Extra Bonus Point

Page 40: Scrum workshop - September 7, 2012
Page 41: Scrum workshop - September 7, 2012

Agile is NOT a magic bullet

Each situation its approach

Master by practice

Page 42: Scrum workshop - September 7, 2012

SCRUM

Page 43: Scrum workshop - September 7, 2012

• Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time.

What is Scrum?

Page 44: Scrum workshop - September 7, 2012

• It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month).

What is Scrum?

Page 45: Scrum workshop - September 7, 2012

• The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features.

What is Scrum?

Page 46: Scrum workshop - September 7, 2012

• 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.

What is Scrum?

Page 47: Scrum workshop - September 7, 2012

• Self-organizing teams• Product progresses in a series of

month-long “sprints”• Requirements are captured as items in a

list of “product backlog”

Scrum Characteristics

Page 48: Scrum workshop - September 7, 2012

• No specific engineering practices prescribed

• Uses generative rules to create an agile environment for delivering projects

• One of the “agile processes”

Scrum Characteristics

Page 49: Scrum workshop - September 7, 2012

The Agile Manifesto–a statement of values

Process and toolsIndividuals and

interactionsover

Following a planResponding to

changeover

Source: www.agilemanifesto.org

Comprehensive documentation

Working software over

Contract negotiation

Customer collaboration

over

Page 50: Scrum workshop - September 7, 2012

Putting it all together

Page 51: Scrum workshop - September 7, 2012

5 Minutes Break

Page 52: Scrum workshop - September 7, 2012

• 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

Sprints

Page 53: Scrum workshop - September 7, 2012

• A constant duration leads to a better rhythm• Product is designed, coded, and tested

during the sprint• Rather than doing all of one thing at a time...

...Scrum teams do a little of everything all the time

Sprints

Page 54: Scrum workshop - September 7, 2012

• During the Sprint, NO CHANGES

• Plan sprint durations around how long you can commit to keeping change out of the sprint

Sprints

Page 55: Scrum workshop - September 7, 2012

Scrum Framework

•Product Owner•ScrumMaster•Team

Roles

•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meeting

Ceremonies

•Product backlog•Sprint backlog•Burndown charts

Artifacts

Page 56: Scrum workshop - September 7, 2012

•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meeting

Ceremonies

•Product backlog•Sprint backlog•Burndown charts

Artifacts

•Product owner•ScrumMaster•Team

Roles

Scrum Framework

Page 57: Scrum workshop - September 7, 2012

• The product owner is responsible for bridging the gaps between the customer, business stakeholders, and the development team.

• The Product Owner is typically a project's key stakeholder with a vision for what is to be built.

Product Owner

Page 58: Scrum workshop - September 7, 2012

• 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

Product Owner

Page 59: Scrum workshop - September 7, 2012

• Adjust features and priority every iteration, as needed 

• Accept or reject work results

• Closely collaborates with the team on an ongoing basis and guides and direct the team (e.g. managing product backlog, feedback, signing off work results)

Product Owner

Page 60: Scrum workshop - September 7, 2012

•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meeting

Ceremonies

•Product backlog•Sprint backlog•Burndown charts

Artifacts

•Product owner•ScrumMaster•Team

Roles

Scrum Framework

Page 61: Scrum workshop - September 7, 2012

• Represents management to the project

• Responsible for enacting Scrum values and practices

• Removes impediments

ScrumMaster

Page 62: Scrum workshop - September 7, 2012

• Ensure that the team is fully functional and productive

• Enable close cooperation across all roles and functions

• Shield the team from external interferences

ScrumMaster

Page 63: Scrum workshop - September 7, 2012

• The ScrumMaster is often considered a coach for the team, helping the team do the best work it possibly can.

• The ScrumMaster is also often viewed as a protector of the team.

• Protects the team from complacency – knows when is the time to push for more

ScrumMaster

Page 64: Scrum workshop - September 7, 2012

•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meeting

Ceremonies

•Product backlog•Sprint backlog•Burndown charts

Artifacts

•Product owner•ScrumMaster•Team

Roles

Scrum Framework

Page 65: Scrum workshop - September 7, 2012

• Typically 5-9 people• Cross-functional:• Programmers, testers, user experience

designers, etc.• Members should be full-time• May be exceptions (e.g., database

administrator)

Team

Page 66: Scrum workshop - September 7, 2012

• Teams are self-organizing

• Ideally, no titles but rarely a possibility

• Membership should change only between sprints

Team

Page 67: Scrum workshop - September 7, 2012

•Product owner•ScrumMaster•Team

Roles

•Product backlog•Sprint backlog•Burndown charts

Artifacts

•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meeting

Ceremonies

Scrum Framework

Page 68: Scrum workshop - September 7, 2012

• Is the planning session before each sprint, where the scope of work for an iteration is determined.

• The purpose of the Sprint Planning is to decide on the sprint commitments, and ensure their content is clearly communicated across the board

Sprint Planning

Page 69: Scrum workshop - September 7, 2012

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

Sprintgoal

Sprintbacklog

Business conditions

Team capacity

Product backlog

Technology

Current product

Sprint Planning

Page 70: Scrum workshop - September 7, 2012

• Team selects items from the product backlog they can commit to completing

• Sprint backlog is created

• Tasks are identified and each is estimated (ideally 1-8 hours MAX)

Sprint Planning

Page 71: Scrum workshop - September 7, 2012

• Collaboratively, not done alone by the ScrumMaster

• High-level design is considered

Sprint Planning

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)

Page 72: Scrum workshop - September 7, 2012

•Product owner•ScrumMaster•Team

Roles

•Product backlog•Sprint backlog•Burndown charts

Artifacts

•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meeting

Ceremonies

Scrum Framework

Page 73: Scrum workshop - September 7, 2012

• At the end of each sprint a sprint review meeting is held. During this meeting the Scrum team shows what they accomplished during the sprint. Typically this takes the form of a demo of the new features – no slides

• No more than two hours of preparation time for the meeting - is intentionally kept very informal

Sprint Review

Page 74: Scrum workshop - September 7, 2012

• Participants in the sprint review typically include the Product Owner, the Scrum Team, the ScrumMaster, management, customers, and developers from other projects if apply

• Project is assessed against the Sprint Goal

• Important to achieve the overall goal of the sprint

Sprint Review

Page 75: Scrum workshop - September 7, 2012

•Product owner•ScrumMaster•Team

Roles

•Product backlog•Sprint backlog•Burndown charts

Artifacts

•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meeting

Ceremonies

Scrum Framework

Page 76: Scrum workshop - September 7, 2012

• It is a brief, dedicated period at the end of each sprint to deliberately reflect on how the team are doing and to find ways to improve

• Done after every Sprint

• Less than 1 hour preferable

Sprint Retrospective

Page 77: Scrum workshop - September 7, 2012

• The entire team, including both the ScrumMaster and the Product Owner should participate, possibly customers and others

• Recommended to do it outside the office

• The next retrospective is often begun by reviewing the list of things selected for attention in the prior retrospective.

Sprint Retrospective

Page 78: Scrum workshop - September 7, 2012

Sprint Retrospective

Whole team gathers and discusses what they’d like to:

Start doing

Stop doing

Continue doing

This is just one of many ways to do a sprint retrospective.

Page 79: Scrum workshop - September 7, 2012

•Product owner•ScrumMaster•Team

Roles

•Product backlog•Sprint backlog•Burndown charts

Artifacts

•Sprint planning•Sprint review•Sprint retrospective•Daily Scrum Meeting

Ceremonies

Scrum Framework

Page 80: Scrum workshop - September 7, 2012

• Happens Daily

• 15-minutes Max

• All Standing (aka. Stand-up Meeting)

Daily Scrum Meeting

Page 81: Scrum workshop - September 7, 2012

• It is NOT for problem solving

• Whole world is invited

• Only team members, ScrumMaster, product owner, can talk

• Helps avoid other unnecessary meetings

Daily Scrum Meeting

Page 82: Scrum workshop - September 7, 2012

• Everyone answers 3 questions:

Daily Scrum Meeting

1. What did you yesterday?2. What will you do today?3. Is anything in your way?

These are NOT status for the ScrumMaster

They are commitments in front of colleagues

Page 83: Scrum workshop - September 7, 2012

•Product owner•ScrumMaster•Team

Roles

•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meeting

Ceremonies

•Product Backlog•Sprint backlog•Burndown charts

Artifacts

Scrum Framework

Page 84: Scrum workshop - September 7, 2012

• 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

Product backlog

Page 85: Scrum workshop - September 7, 2012

• Prioritized by the product owner

• Reprioritized at the start of each sprint

Product backlog

Page 86: Scrum workshop - September 7, 2012

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

As a hotel employee, I can run RevPAR reports (revenue-per-available-room)

8

Improve exception handling 8

... 30

... 50

Page 87: Scrum workshop - September 7, 2012

• is a short, one - or two-sentence, description of what the team plans to achieve during the sprint.

• It is written collaboratively by the Team and the Product Owner.

The Sprint Goal

Page 88: Scrum workshop - September 7, 2012

• Implement basic shopping cart functionality including add, remove, and update quantities.

• The checkout process—pay for an order, pick shipping, order gift wrapping, etc.

Sprint Goals Sample Ecommerce App

Page 89: Scrum workshop - September 7, 2012

•Product owner•ScrumMaster•Team

Roles

•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meeting

Ceremonies

•Product Backlog•Sprint Backlog•Burndown charts

Artifacts

Scrum Framework

Page 90: Scrum workshop - September 7, 2012

• Individuals sign up for work of their own choosing

• Work is never assigned• Estimated work remaining

is updated daily

Sprint backlog

Page 91: Scrum workshop - September 7, 2012

• Any team member can add, delete or change the sprint backlog

• If work is unclear, define a sprint backlog item with a larger amount of time and break it down later

Sprint backlog

Page 92: Scrum workshop - September 7, 2012

• The Product Owner does not get to say, "We have four sprints left so you need to do one-fourth of everything I need.

Sprint backlog

Page 93: Scrum workshop - September 7, 2012

• It is up to the Team to determine how much they can do in the sprint

• Work for the sprint emerges

• Update work remaining as more becomes known

Sprint backlog

Page 94: Scrum workshop - September 7, 2012

Sample Sprint backlog

TasksCode the user interfaceCode the middle tier

Test the middle tier

Write online help

Write the foo class

Mon8

16

8

12

8

Tues4

12

16

8

WedThur

4

11

8

4

Fri

8

8

Add error logging

8

10

16

8

8

Page 95: Scrum workshop - September 7, 2012

Sprint backlog

• During the sprint, team members are expected to update the sprint backlog as new information is available, but minimally once per day. Many teams will do this during the daily scrum.

Page 96: Scrum workshop - September 7, 2012

Sprint backlog

• Once each day, the estimated work remaining in the sprint is calculated and graphed by the ScrumMaster, resulting in a Sprint Burndown chart

Page 97: Scrum workshop - September 7, 2012

•Product owner•ScrumMaster•Team

Roles

•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meeting

Ceremonies

•Product Backlog•Sprint Backlog•Burndown Charts

Artifacts

Scrum Framework

Page 98: Scrum workshop - September 7, 2012

Sprint Burndown Chart

Page 99: Scrum workshop - September 7, 2012

Sprint Burndown ChartH

ou

rs

40

30

20

10

0Mon Tue Wed Thu Fri

TasksCode the user interfaceCode the middle tier

Test the middle tier

Write online help

Mon8

16

8

12

Tues Wed Thur Fri4

12

16

7

11

8

10

16 8

50

Page 100: Scrum workshop - September 7, 2012

Sprint backlog

• The team does its best to pull the right amount of work into the sprint but sometimes too much or too little work is pulled in during the Sprint Planning meeting

• In this case the team needs to add or remove tasks and the Product Owner consulted

Page 101: Scrum workshop - September 7, 2012

10 Minutes Break

Page 102: Scrum workshop - September 7, 2012

Estimation - Planning Poker

Page 103: Scrum workshop - September 7, 2012

Portions of this Presentation are from the following sources:

• Mike Cohn, Mountain Goat Software, LLC• Scrum.org • Scrum Alliance, scrumalliance.org

Page 104: Scrum workshop - September 7, 2012

Thank you for [email protected]