Scrum Training - Salesforce

8/12/2019 Scrum Training - Salesforce

1/83

ADM/Scrum Training

May 2008

Agenda

Introduction

Review Agenda

Determine timing, logistics and breaks


2/83

Customer Exercise

The Scenario

In this exercise, you and your team need to produce a market

shattering new product

Your product must offer some essential functionality that is

already in the marketplace (straight lines)

e.g. if it were an email application, you would have to offer the ability to send

mail or you would never succeed

Its also very important for you to gain market share by creating

excellent new functionality that the market hasnt seen yet! (curvy

lines)


3/83

What Were Going To Do

Were going to split into teams

Decide amongst yourselves who will play the role of:

Customer

Product Owner

Delivery

The other teams are your competitors

You must create an exact copy of the vision (minus thecopyright, title, border, and the lines do not need to be the samethickness)

What You Need To Know

Customer: You have the vision of the product. You are the onlyone who can see it.

Product Owner: You must translate what the Customer is lookingfor and relay that to the Delivery team. You may make personalnotes but you cannot show them to the Delivery team.

Delivery: You must deliver the product. You will have paper andpencil. You are the only one who can draw on the paper.

You have ten minutes to deliver the product


4/83

Introduction

Phased Development Process(defined, waterfall)

Plan Design Build Test

Surprise!

Documentation,

Signoffs, Handoff

Documentation,

Signoffs, Handoff

Documentation,

Signoffs, Handoff

Great if you know exactly what you want

and wont change your mind


5/83

Changes wi th a Phased Process

Plan Design Test

Documentation,

Signoffs, Handoff

Documentation,

Signoffs, Handoff

Documentation,

Signoffs, Handoff

Change

Request

Build Bug Fix

Launch

Change interrupts the flow

start finishanalysis design code test

The design of the waterfall means that we will always

be at our most vulnerablejust when we least want to

be and that defects will be found where they are the

most expensive to fix.

test

One More Thing about Phased Development

start finishproject timeline

this is the place we would

least like to find any defects


6/83

Agile Development

Incremental releases Short Iterations of 1-4 weeks

Feedback Feedback Feedback

v1.0 v1.1 v1.2

Agile Development

Do a little bit of everything every cycle


Plan

Design

Test

Build Fix Bugs

Plan

Design

Test

BuildFix Bugs

Plan

Design

Test

BuildFix Bugs

Plan

Design

Test

BuildFix Bugs


7/83

Agile Development

Change ChangeChange


Expects change Change enables learning

Its all in the System

Simple, clear purpose and principles give

rise to complex, intelligent behavior.

Complex rules and regulations give rise

to simple, stupid behavior. Dee Hock, VISA


8/83

Our Story

The Backstory

Fast

Innovative

Successful

Growing


9/83

7 years later

35,000+ customers

900,000+ subscribers

100+ Million transactions per day

200+ in Technology!

Butuh oh


10/83

Its getting harder

to get things done


11/83

so whats the deal?

Waterfall process Un-predictable

Delayed releases

Velocity slowdown

No visibility

Late feedback

Technical Debt

Death march Loss of cred

Over budget

Scope creep

Elegant

and a little messy


12/83

Core Values

KISS

Listen to your customers

Iterate

What is ADM?

ADM is a modified Scrum/XP style of product development

that is specific to Salesforce.

It employs Scrum project management framework and

adopts certain XP practices.


13/83

What is ADM?

Re-factoring

Self-organizing

Predictable releases

Transparent

Ftest - Selenium

Continuous integration

Debt free

Just-in-timeIterative

Always Potentially Releasable

Time-boxed

User stories

AgileLean

Early feedback

Code Reviews

Collective Code Ownership

Self-correcting

Agile


14/83

Agile is a great buzzword.

Who doesnt want to be Agile?

No one says,

Thanks, Id rather be inflexible

and slow to respond.

Agile

Is a flexible framework of common values

The most popular are Scrum, XP, and

Lean

A Common-sense approach


15/83

Process and toolsProcess and toolsIndividuals andinteractions

Individuals andinteractions over

The Agile Manifesto

Comprehensive

documentation

Comprehensive

documentationWorking softwareWorking software over

Contract negotiationContract negotiationCustomer

collaboration

Customer

collaborationover

Following a planFollowing a plan

Responding to changeResponding to change over

While we value the items on the right, we value the items on the left more.

Agile Mythology.


16/83

This is NOTAg ile

Cowboy coding No planning

Poor quality

Compressing the schedule

The organization may gain short term speed but at the cost of

long term pain.

Agile Values

Communication

Simplicity

Feedback

Courage

Respect


17/83

Principles

Humanity

Economics

Mutual Benefit

Improvement

Diversity

Reflection

Flow

Opportunity

Redundancy

Self-Similarity

Failure

Quality

Baby Steps

Accepted Responsibility

Scrum


18/83


19/83

Eliminates waste

Increases throughput

Provides transparency

Looks very simple but very hard; it causeschange

Makes dysfunction very visible

What is Scrum?

Scrum is NOT


20/83

Scrum

Product Backlog1

Scrum 101

789101112

1234

56

13

No Changes(in Duration or Deliverable)

Commitment

789101112

123456

13

Daily Stand-up

3

Team Retrospective

Challenges

Testing Build breaks

Improvement

5

Sprint Planning2

Potentially Shippable

4 Sprint Review

Sprint

24 weeks


21/83

Planning

Prediction

To get predictability we needto stop predicting

We need to make decisionsbased on fact not forecasts.


22/83

Multi-Level Planning

Product Vision

Roadmap

Release Plan

Sprint Plan

Daily Plan

Q1 Q2 Q3

R1 R2 R3


Product Vision

Roadmap

Release Plan

Sprint Plan

Daily Plan

Q1 Q2 Q3

R1 R2 R3


23/83

Product Vision

Vision &Roadmap

What is your market

Who are your customers

How you will make

money

What is your product

vision.


Product Vision

Roadmap

Release Plan

Sprint Plan

Daily Plan

Q1 Q2 Q3

R1 R2 R3


24/83

Minimum Market Feature Set

Always

7%

Often

13%

Sometimes

16%

Rarely

19%

Never

45%

Standish Group study reported at XP2002 by Jim Johnson, Chairman

Often or AlwaysUsed: 20%

Rarely or NeverUsed: 64%


Product Vision

Roadmap

Release Plan

Sprint Plan

Daily Plan

Q1 Q2 Q3

R1 R2 R3


25/83

Release Planning

Communicate a common

vision for the release

Initial Design

Align team on proposed

functionality

Determine targetfunctionality for the release

Release Planning

Groom User Stories small enough

to be effective for sprint planning

Determine the relative size of the

user stories in story points

Determine Release Functionality

based on velocity

Identify Dependencies


26/83

Release Planning in Scrum

Release planning is based on Velocity

Velocity is a measure of how much

Product Backlog the team actually

completes over time.

Product BacklogBacklog Mapped out in Sprints

Silly features17

To type16

Monkeys want15

Why would14

Year13

Webvan12

Last11

Areso10

Cosmo9

Networks8

Social7

Wiki6

Dolls house5

Movies for kids4

Tick-tock feature3

Clock2

Feature1

Sprint 1

Sprint 2

Sprint 3

Sprint 4

Sprint 5


27/83


28/83

Sprint Planning

Determine the Sprint Goal

Determine work necessary

to complete the goal (with

time estimates)

Make commitments for the

Sprint

Sprint Planning Meeting

Team dog piles on user

stories

Team figures out how to deliver

Sprint Goal even without a

resource on the team who

normally does a particular type

of work

Product Owner may negotiate

but Team always determines

what they can complete during

the sprint


29/83

Sprint Planning Step 1

Product Owner and team discuss thelatest product backlog and thegoals of the Sprint.

7

8

9

10

11

12

1

2

3

4

5

6

13


Team works out available hours for the Sprint


30/83


The team goes through the items in thebacklogand breaks them into tasks

Each task is estimated

Team members volunteer for tasks

Stop when you are full.

Task: Configure database

and SpaceIDs for Trac

7

Sprint Backlog

Tasks necessary to

complete user stories

Many-to-one relationship

with user stories

Coding, testing, automation,specs, doc, design, etc.


31/83

Sprint Backlog

Team expands items on the

Sprint Backlog into specific

tasks, time estimates in hours,

signs up for ownership

Critical that The Team

selects items and size for

Sprint Backlog

Managed through Scrumforce

Commitment Driven Planning

Take highest priority item

Decompose into tasks

Estimate each task (whole team)

Can we commit to this?

If yes, try another backlog item

If not, remove it but try a smaller one

No one signs up for tasks yet


32/83

Abnormal Terminations

In extreme circumstances the

Sprint may be terminated

Cost:

Everything reverts back to the

original state prior to the Sprint

planning meeting.

STOP

Estimation


33/83

Story pointsIdeal daysTeam daysT-Shirt SizesHours

Common Product Backlog Estimating Units

High Level Estimates

Story Points

A measure of the relative size

of a feature

Based on how much and how

hard to do

Agreed-upon unit

Helps compare costs.

50As a user I can create a profile to

display information about myself

8As a guest, I can add one photo to my

profile page

Backlog item Estimate

As a premium member I can add up to

ten photos to my profile page5

As a premium member, I can add video

to my profile page40

As a guest, I can add photos to my

profile page 30

As a user I can add people I like to a

hot list30


34/83

Tracking

Tracking Progress

Track the work remaining

Do not track actual time worked

Update daily.


35/83

Task board tracking

70

Another sample task board


36/83

Burndown Charts

0.0

5.0

10.0

15.0

20.0

25.0

30.0

35.0

40.0

45.0

50.0

2/1

2/2

2/3

2/4

2/5

2/6

2/7

2/8

2/9

2/10

2/11

2/12

2/13

2/14

2/15

2/16

2/17

2/18

2/19

2/20

2/21

2/22

2/23

2/24

2/25

2/26

2/27

2/28

IdealDays

Actual Baseline

Production support

Resolution of dev

assumptions

Added Tasks

Added March Tasks!


37/83


38/83

Will this sprint finish on time?

Mond

ay

0

50

100

150

200

250

300

Tuesd

ay

Wednesd

ay

Thursday

Frid

ay

Mond

ay

Tuesday

Wednesday

Frida

y

Thursd

ay

350

Putting it into Practice


39/83

XP Game

This game is called the XP Game Developers - estimate

Product owners - prioritize based on business value and estimate

Developers execute

Find easiest one and give number 2

There might be something easier in the future

Estimate other stories relative to 2

Think about complexity and time as it may be simple yet take a long time

There will be one release with three iterations, each of 3 minutes

YOU ONLY DO ONE STORY AT A TIME (together)

XP Game Iteration 1


40/83

Sprint Review

Sprint Review A demo by the team of: Complete

Fully tested

Potentially shippable features

Only functionality that meets

Done criteria is demoed

Team declares what they

committed to doing in the Sprint

and did not get done

Feedback from customers and

stakeholders drives design

changes for future sprints

This is the

Sprint Review

This is the

Sprint Review

Review


41/83

Sprint ReviewUser Story Doneness Checklist

User documentation complete and checked in.

All UI labels ready for localization vendors.

Usability testing scheduled when necessary, and feedback incorporated into

backlog.

UE has reviewed any new features; P1 and P2 UI bugs fixed.

Performance/scalability impact ascertained and sys testing scheduled if

required.

All resolved bugs verified and closed.

100% of test cases logged in QA Tracker and executed in a QA environment,

and all P1/P2 cases passing.

Code Coverage of 70% (or as agreed with team)

No open P1 & P2 bugs

No open regressions. Automated tests written and reviewed for all regressions.

Code checked in and follows department standards.

BT & Profile

Perm

Setup

Page

Handshake

POCDone Criteria

User Stories

All defined Acceptance Criteria for a user story have been met.

Code

Code implementing the user story functionality is checked in and follows department standards.

No open regressions (you break it, you own it), with automated tests written for all regressions.

No open P1 & P2 bugs for the implemented functionality in the sprint.

Quality

Code Coverage of 70%

Test plan, cases and execution for sprint functionality, regression and cross functional testcases related to sprint functionality, need to be 100% executed, and all P1/P2 cases passing.

All resolved bugs have been verified and closed for the sprint functionality.

Definition of Done


42/83

Performance/Scalability

Performance/Scalability impact of sprint functionality understood and quantified, and systesting

scheduled, if required, with the sys test team.

User Experience

UE reviewed new features or significant changes in the UI, feedback incorporated, all resulting

P1 and P2 UI bugs fixed.

Usability testing completed, feedback has been incorporated into the backlog.

Localization

All UI components have labels ready for localization vendors.

Documentation

User doc describing all aspects of sprint functionality complete / checked in.

Definition of Done

Retrospective


43/83

Sprint Retrospective

What is it?

A meeting at the end of

each Sprint so the team can

Inspect and Adapt the

processChallenges


Improvement

Sprint Retrospective

How do you do it?

Team, Scrum Master and Product

Owner have a ~1-2 hr meeting

3 questions are asked:

Whats working

Improvements

Things to try in the next

Sprint

Challenges


Improvement


44/83

What a Retrospective is NOT

Retrospectives are NOT about blame Problems arise. The focus is on what we can learn from what

happened

Retrospectives are NOT a witch hunt

Retrospectives are NOT about gathering specific

information

They are a free-flowing brainstorm on opportunities and ways

to resolve them


45/83

Iteration 2

Iteration 3


46/83

Getting Started


47/83

Determine your Team

Agile teams are cross-functional and persistent

Determine your Scrum Master

Determine your Product Owner

Assemble all cross functional members that can fully

perform all of the required functions

Get a coach (if you want one)

Roles


48/83

The Scrum Master

A facilitator and coach

Removes impediments

Protects team from external

influences

Improves productivity of team so

each user story is potentially

releasable

Keeps progress information up-

to-date and visible to all

Product Owner

Product visionary

Maximizes business value

Prioritizes the Product

Backlog

Fully engaged


49/83

The Scrum Team

Cross-functional Shared Commitment

Self organizing, Self

correcting. Teams decide

best way to deliver

Members are dedicated

resources (as much as

possible)

Optimally 6-10 people

Managers

Remove impediments

Provide vision andleadership

Provide resources

Less micro-managementand more enablement


50/83

Discuss: Roles

Does the ScrumMaster have to be a Project Manager?

Can one person serve as both ScrumMaster and

Product Owner?

Who manages the team members?

Who assigns tasks to the team?

Environment


51/83

Environment

Everyone in same location

Open space without barriers

Resources available; phone, whiteboards, meeting

space etc.


52/83


53/83

Not this

! ? !

Kicking Off


54/83

Kicking off

Product

Vision

Share understanding on:

The Product Vision

Your customers

The market

Why you are doing this and

what you hope to achieve.

Write a One-Pager

Elevator statement / Problem to sol ve

ForwhothatUnlikeHow do you know?

Who are our customers? Benefits

People who work in Those who need a

How will we create business value?

Share content with

Personalized ads on

Risks?

Technology unknowns

Dependencies

Performance attributes

3000 hits/hour

3 clicks to get to core contentScale to 100,000,000 users

Scope

Resources

Schedule

Quality

Fixed Firm Flexible

Sign-ups xxx

Milestones: dates or features to hit

Xyz features xxx

Abc features xxx

How do we know we succeeded? (metrics)

More

Flexible

Tradeoff Matrix


55/83

Brainstorming

Brainstorms are a goodway to gather

requirements for the

Backlog

Best when generated by

the whole team.

Hot list

Share photosShare video

Mobile personals

VirtualSpeed dating

Create a Product Backlog

High Priority items at the top

Get less detailed as you go

down

Estimates high-level to help

compare items in relation to

each other.

50As a user I can create a profile to

display information about myself

8As a guest, I can add one photo

to my profile page

Backlog item Estimate

As a premium member I can add

up to ten photos to my profile

page

5

As a premium member, I can add

video to my profile page40

As a guest, I can add photos to

my profile page 30

As a user I can add people I like

to a hot list30


56/83

Product Backlog

Key to success of Scrum

Master list of functional and non-

functional items desired in the

product (features, bugs, re-factoring)

Anyone can add to Product Backlog

Product Owner is the only person

that prioritizes Product Backlog

Includes relative estimate of size of

features (design, code, test,

automate, refactor, doc, fix bugs)

Product Backlog Sample


57/83

User Stories

Whats a User Story?

Basic unit of scope for an agile project

Describes a WHO, WHAT and WHY scenario

Describes real business value

A promise for a conversation Very different from traditional requirements documentation which seek to

ensure all details are present in order to form a contract

Has acceptance criteria to assert its behavior.


58/83

A user story template

Backlog items can be written as User Stories

Express user needs in terms of what the user wants to

achieve

Example template for this:

As a , I want to

so that

Acceptance Criter ia

The product owners acceptance criteria should be added to a story These are essentially tests

As a guest, I want to addone photo to my profilepage so that my friendscan identify me

As a guest, I want to addone photo to my profilepage so that my friendscan identify me

Verify user can uploadphoto

Verify user can only upload

one photoVerify confirmation messagedisplayed when photo isuploaded

Verify premium upsellappears on confirmation page

Verify user can uploadphoto

Verify user can only upload

one photoVerify confirmation messagedisplayed when photo isuploaded

Verify premium upsellappears on confirmation page


59/83

If in doubtINVEST!

Independent

Negotiable

Valuable

Estimable

Sized Appropriately

Testable

INVEST

A good user story:I Independent

N Negotiable V Valuable

E Estimable

S Small

T Testable

Hows th is Story?

As: User

I want: a flexible extensibleframework that allows me to provideweb services access to my LDAPdatabase

So that: ???


60/83

What About th is One?

As a Student

I want to receive email notification with appropriate detail when I submit a

pending registration request, whether I am confirmed or waitlisted, if a

class is cancelled, or if I self-withdraw from a class

So that I know my registration status, know where my class is located (if

confirmed), and know who to contact if I have questions.

A good user story:I Independent

N Negotiable

V Valuable

E Estimable

S SmallT Testable

It could be re-writ ten as:

As a student

I want to receive email notification when I submit a registration

request which informs me of my status

So that I know my registration status, know where my class is

located and know who to contact if I have questions

Acceptance criteria:

If student submits registration request and it is confirmed, ensure

email X is sent (with confirmation, class info and contact person)

[note: you may actually just include the email template here] If student submits registration request and they are waited listed,

ensure email Y is sent


61/83

And

As an administrator

I want to be able to cancel a class and inform confirmed registered

students of the cancellation

so everyone is aware of the schedule change


Ensure a class can be cancelled by X action

Ensure cancellation email Z is sent to all registered students

Ensure cancellation email A is sent to waitlisted students

And

As a student

I want to be able to withdraw from a class

so that others can take the spot if I am unable to attend


Ensure student can withdraw by doing ABC

Ensure student receives confirmation email X

Ensure student is removed from class registration and if waitlisted

students are listed, the next one on the list is now emailed and

asked to register (or registered automatically etc)this one couldbecome its own story depending on the discussion with the dev

team as to complexity


62/83

Lets Write a Story

Exercise :

In 5 mins either alone or with a pair, write a user story for:

Making yourself a coffee

in terms of AS I WANT TO SO THAT

With two examples of acceptance criteria

Use the index cards provided, writing the acceptance criteria on the back

Questions

Who can contribute to the product backlog?

Who prioritizes the product backlog?

Do you have to use user stories?

How often is the product backlog reviewed and revisited?


63/83

Daily Scrum

Daily Scrum

> 15 minute meeting

What I did yesterday

What I plan on doing today

What is blocking me


64/83

Daily Scrum

Scrum Master facilitates stand up: Side conversations are put on the parking lot

Blocks and issues are identified, and action plans are created

Follow-up on resolutions

Scrum Exercise


65/83

Scenarios

Exercise: Great Scrum Teams

Read the scenario

Take a few minutes to discuss with your team what a great

Scrum Master would do in this situation

Be ready to share your thoughts with the group


66/83

Scenario 1

The VP of the group appears in the middle of the Sprint,and says to you: one of our clients has a special

request which if we can complete it, we will win $1

million in business.

Scenario 2

The product owner says that he's not going to be

available to attend the Sprint planning meeting, but he

doesn't mind if the team goes ahead and does it without

him.


67/83

Scenario 3

In the middle of the Sprint, one of the team membersmanager comes and says she needs to pull him off the

project for a couple days, to work on something else.

Scenario 4

It's halfway through the Sprint, and the team is way

behind on progress. It looks like there's no way it's

going to finish what it committed to during the Sprint.


68/83

Scenario 5

One member of the team looks really unhappy. Heseems very distracted, and he's way behind on the

tasks that he committed to complete.

Scenario 6

One member of the team speaks up and says he thinks

the retrospective is a waste of time; several other

members of the team murmur in agreement, and

someone else suggests that the team stop doing the

retrospective.


69/83

Scenario 7

The team appears to be very stressed out. They arehaving to work late most nights of the week, and they

even have to work Saturdays every now and again, in

order to meet their Sprint goals. You hear comments

like scrum is awful it forces us to work so hard.

Scenario 8

A team member has recently moved. He mentions that

he is trying to find daycare for his daughter and its

blocking him from doing his work.


70/83

Agile Practices

Some Agile Practices to Think About

Technical

Test first development


Pair programming

Automated functional testing

Code Reviews

Coding Standards

Design

Simple design

Thin vertical slices

Architecture spikes

Team Whole team

Cross functional

Self-organized

Retrospectives

Continuous improvement

Office Hours

Product Management

Minimum market feature set

Product Vision

Product Backlog

One Pager

User Stories

Project

Iterative delivery

Information radiators

Burndown charts

Scrumforce

Planning Daily stand-ups

Release Planning

Sprint Planning

Sprint review meetings


71/83

What is ADM?

Re-factoring

Self-organizing

Predictable releases

Transparent

Ftest - Selenium


Debt free

Just-in-timeIterative

Always Potentially Releasable

Time-boxed

User stories

AgileLean

Early feedback

Code Reviews

Collective Code Ownership

Self-correcting

Scaling Agile


72/83

Large Projects are Hard

Generally more technically complex

Many people causing communication breakdowns

Lots of dependency management

Difficult to maintain transparency of overall progress

Scaling Top 4

Focus on communication!

Create ONE team

Get your team structures in line

Do continuous integration on the whole system


73/83

Building Teams

Avoid splitting across functional lines QA in one location, Product owners in another, Engineering in a third

Integrations after completion of development Delivery of business value at the end

Rather structure along features for a cross functional workstream For ensuring business value and the customers advantage

Features shouldnt be split across teams The feature provides a joint goal and thus enforces team spirit

Comprehends all necessary roles

Product Owner, Engineering, QA

Comprehends all necessary expertise

UED, database, configuration management

Some coordination roles must work across all workstreams

Chief Architect

Chief Product Owner

Scrum of Scrum Master

Scaling the Product Owner

Product

Owners

Product Line

Owners

Chief Product

Owner


74/83

Communication & Dependency Management

Scale Communication

Each workstream has their daily scrum

Use Scrum of Scrums to cross-communicate

Not limited to Scrum Masters, any functional role may

find this useful


75/83

The Four Questions

1. What has your team done since we last met?

2. What will your team do before we meet next?

3. Whats in your teams way?

4. What are you about to put in another teams way?

Scrum of Scrums


76/83

Scrum of Scrums of Scrums

Share Start and End Dates

Team 1Team 1Team 1 Team 1Team 1Team 1

Team 2Team 2Team 2Team 2Team 2Team 2


FinishFinish StartStart


Team 2Team 2Team 2Team 2Team 2Team 2


Dont stagger sprints like this:

Synchronize sprint starts instead


77/83

Build Some Infrastructure Initially

Architecture

Development environment

Standards Interfaces

Some tangible piece of business value

Share the Product Backlog

Its usually best to share a common product backlog

among all of the teams

Think of one product backlog with multiple views into it


78/83

More Items For the Product Backlog

1. Devise and implement coding standards

2. Establish an approach to having customers develop

acceptance tests

3. Set standards for frequency of checking in code

4. Investigate and implement code review (or pair programming)

5. Upgrade working environment and tools for teams

Integrate the Builds

Midnight

2 a.m.

3 a.m.


79/83

Tracking, Transparency and Tools

With Size Comes Process

Provide a framework for cohesion but dont stop teams frommaking their own decisions

Remember good project management--record risks and criticalpath

Avoid the temptation to start with lots of complex process

If it works at one level, looks for ways to scale it up

Only add process when its needed


80/83

Release Tracking Work Remaining

Iteration10

50

100

150

200

250

300

420

(Story Points)

Iteration2

Iteration3

Iteration4

Iteration5

Iteration6

Iteration7

Iteration8

Iteration9

Iteration10

Iteration11

Ideal

Actual

Tools

Electronic tools still need to be easy Focus of a tool is to provide transparency to whole team

Should roll-up all teams progress towards end goal

Should allow for teams to take on others work if one team is at risk

Recognize the need for redundancy Using electronic tools should not stop teams for using physical cards

and burndowns


81/83

Resources

External Resources

Scrum

http://www.scrumalliance.com

http://www.controlchaos.com

http://www.mountaingoatsoftware.com

Yahoo Groups: [email protected]

[email protected]

[email protected]

[email protected]

[email protected]


82/83

Further Reading

Agile Project Management with Scrumby Ken Schwaber

User Stories Applied by Mike Cohn

Agile Estimating and Planning by Mike Cohn

Agile Retrospectives: Making Good Teams Great by EstherDerby and Diana Larsen

Lean Software Development:Mary Poppendieck

Congratulations!

Any questions?

[email protected]


83/83

Scrum Training - Salesforce

Documents

Transcript of Scrum Training - Salesforce