compendium for certified scrum master and certified scrum...

Compendium Compendium for Certified Scrum Master andfor Certified Scrum Master andCertified Scrum Product OwnerCertified Scrum Product Owner

改改 ScrumMaster.dk –ScrumMaster.dk –舎舎AgileLeanHouse A/SAgileLeanHouse A/S

Compendium For Certified Scrum Master and Certified Scrum Product Owner classes

Version 2.0, © Copyright 2013-2017改改 ScrumMaster.dk –ScrumMaster.dk –舎舎AgileLeanHouse A/SAgileLeanHouse A/S

www.ScrumMaster.dk [email protected] [email protected] Lysholt Allé 6, DK-7100 Vejle, DenmarkTel: +45 6168 9118

We have known since the 1940s that there is a better way to achieve results than through top-down driven planning. W. Edwards Deming helped Japan recover after WWII. We learned about all this in the West under the name of “Lean”. But very often we have only seen this as an exercise in efficiency and have forgotten the second part so important to W. Edwards Deming and the early Japanese implementation: “Respect for the human being, allow them pride of workmanship!”. Scrum is the leading “Lean” framework for leading projects and development of new products and services.

Kurt [email protected]

http://www.ScrumMaster.dk/

http://www.AgileLeanHouse.com/

mailto:[email protected]



Core Scrum Compendium 12.0

改改Scrum in 60 secondsScrum in 60 seconds A Product Owner creates a vision and plan for the result, an ordered list of

Items: requirements, qualities or wishes – The Product Backlog.

At Sprint Planning the Team collaborates with the Product Owner in finding the best possible set of Items, that can be accomplished in the upcoming Sprint of (1), 2 to 4 weeks length.

A Team of (3), 5 to 9 people commits to complete this Sprint Goal and work.

Every day in the Sprint the Team holds Daily Scrum and synchronizes:

What have I accomplished towards the Sprint Goal since yesterday?

What will I accomplish until tomorrow towards the Sprint Goal?

Are there any Impediments limiting my progress?

During the Sprint, the Team collaborates with the Product Owner in refining the top Items in the Product Backlog, so that they are ready to be pulled into future Sprints. This is called Product Backlog Refinement.

At the end of the Sprint a Sprint Review is held, where the accomplishments achieved in the Sprint are presented to the Stakeholders for information and Review. Feedback is reflected in the Product Backlog.

The Scrum Master then facilitates a Sprint Retrospective where the Whole Scrum Team reflect on the Sprint just completed and seek to come up with improvement to the process, the tools and the collaboration.

Each Sprint results in a set of completed Items or qualities, that are fully Done according to the Done Criteria, therefore they potentially can be brought to use – this is a Product Increment.

The Team repeats the Sprint cycle until the Product Owner decides that the desired business objectives are sufficiently fulfilled and the result is brought to use.

The Scrum Master is a servant leader who facilitates collaboration and has the responsibility for the process and for achieving the state of constant improvement. The Scrum Master protects and coaches the Team and the Product Owner.


改改The Scrum FlowThe Scrum FlowImprovement BacklogSprint backlog

To do Progress Done

ProductBacklog

Refinement

SprintPlanning

#1

SprintPlanning

#2

SprintReview

DailyScrum

SprintRetrospective

Product IncrementIdea &

VisionProduct Owner. Responsible for

business value, ROI and prioritization. Owns Product Backlog

product backlogNext

+1

+2

+3

++

Out of scope

New

Product BacklogOrdered list of requirements

Scrum Master. Responsible for process and removing impediments. Owns Impediment BacklogTeam. Responsible for

creating product and results. Owns Sprint Backlog

Selected Backlog

Product/Release Burndown

Sprints

Remain

Ideal

Ideal

P o

i n t s

600

500

400

300

200

100

06 7 8 954321

Sprint Burndown

D a ys

Remaining

Ideal

T a s k s L e

f t

60

6 7 8 9

50

5

40

4

30

3

20

2

10

10

Stakeholders. Users, Customers, Management. Input to Product Backlog, participate and help


改改Strength of a TeamStrength of a Team

# Question 1 2 3 4 51. Do I know what is expected of me in my team?

2. Do I have the materials and equipment, I need, to do my work right?

3. At work, do I have the opportunity to do what I do best every day?

4. In the last seven days, have I received recognition or praise for doing good work?

5. Does my supervisor, or someone in my team, seem to care about me as a person?

6. Is there someone in my team who encourages my development?

7. In my team, do my opinions seem to count?

8. Does the mission/purpose of my team and company make me feel my job is important?

9. Are my co-team-members committed to doing quality work?

10. Do I have a best friend in my team?

11. In the last six months, has someone in my team talked to me about my progress?

12. This last year, have I had the opportunity at work to learn and grow?


改改Project TemperatureProject Temperature

# Question 1 2 3 4 5

1. Has the project generally delivered the expected value to the stakeholders?

2. How close are the deliverables to the stakeholders' (possibly revised) expectations?

3. How close is the project’s timeline to the stakeholders' (possibly revised) expectation?

4. How close is the project’s budget to the stakeholders' (possibly revised) estimate?

5. How close is the project’s quality to the stakeholders' (possibly revised) expectation?

6. How well did you handle discovered information or stakeholders' changed priorities?

7. Does the project generally meet your own expectations?

8. Do the individuals in the project generally take responsibility for the work?

9. Can the project Team generally solve the issues that come up in the project?

10. Can the team keep up a steady pace instead of working in starts and stops?

11. Does the work in the project give a sense of satisfaction and challenge to grow?

12. Would you choose to work on this project again, if you had the choice?


改改Complexities, Uncertainties & Empirical Process ControlComplexities, Uncertainties & Empirical Process ControlRalph Stacey's Agreement & Certainty Matrix

Simple Complicated Complex Chaos

100%

0%

0% 100%Uncertaincy

Probability of SuccessEmpiric

process model,Scrum

Area of improvement

Defined processmodel

Complicated Complex

Chaos

Simple

External Dependencies

Far from Certainty

Close to Certainty

Far

from

A

gre

emen

tC

lose

to

Agre

emen

t

Technology & tools

Spec

ific

ati

ons

& r

equir

emen

ts

It can’t be done! Get another job

Empirical process control (inspect and adapt) is

mandatory for results to converge and emerge

Empirical process control improves

results

Defined process control works

PDSA

Plan

Do

Study

Act


改改Dave Snowden: Cynefin – about ComplexityDave Snowden: Cynefin – about Complexity

Complex Enabling constraints

Loosly coupled probe-sense-respond Emergent Practice

Complicated Governing constraints

Tightly coupled sense-analyze-respond

Good Practise

Chaotic Lacking constraint

De-coupled act-sense-respond Novel Practice

Obvious Tightly constraints

No degress of freedom sense-categorise-respond

Best Practice

Ordered, cause and effect, but difficult. Analysis or experts

are required.

Ordered, cause and effect. A reasonable person can see how this can be solved

Order seen in retrospect. Emerging

knowledge, safe-to-fail- experiments.

No order to be seen Action to stabilize is

required.

Zone of complacency. Over-reliance on structure, risk of

catastrophic failure

Disorder, missing perception of actual

domain, react as usual

Dave Snowden1954 - ...

Tight constraintsNo degrees of freedom

Governing constraintsTightly coupled

Enabling constraintsLoosely Coupled

Lacking constraintsDe-coupled


改改Scrum in the Complex DomainScrum in the Complex Domain

Scrum can be understood as a set of chosen and Scrum can be understood as a set of chosen and self-imposed constraints in the complex domainself-imposed constraints in the complex domain

A r tifacts

The Scrum Pl a ying field

Activities Sprints

Roles


改改The Scrum Flow – Odd-eThe Scrum Flow – Odd-e

http://scrumprimer.org/anime


改改The Scrum Flow – Schwaber & SutherlandThe Scrum Flow – Schwaber & Sutherland


改改The Scrum Flow – German versionThe Scrum Flow – German version

Roles Artifacts Meetings Organizational Process

Scrum Master Responsible for process, coaching and removing impediments

Team Responsible for creating product and results, manages Sprint Backlog

Management/Users/Stakeholders Observe and advise, input to Product Backlog, help remove impediments

Product Backlog ■ Ordered list of requirements,

issues, user stories■ Owned by Product Owner■ Anybody can add to it■ Only Product Owner prioritizes■ Product Burndown chart

Sprint Backlog ■ Sprint Goal: One-sentence

summary■ List of tasks■ Showing status’ of tasks■ Owned by Team■ Only Team modifies it■ Possibly extend with Sprint

Burndown■ Updated daily

Impediment Backlog ■ List of impediments and

improvements■ Publicly visible■ Owned by Scrum Master■ Updated daily

Sprint Planning ■ 2 * 2-4 hours, estimates MUST be ready■ #1, In: Product Backlog, existing product,

business and technology conditions■ Out: Selected highest priority items in Product

Backlog; declare Sprint Goal

■ #2: Team turns selected Items into Sprint Backlog and breaks down to tasks

■ Out: Sprint Backlog

Product Backlog Refinement

Daily Scrum ■ Same time and place every day, 15 min.■ For the Team, all can attend, only Team and

Scrum Master speak, questions: ■ 1) What did you accomplish yesterday?

2) What will you accomplish today? 3) Any Impediments?

■ Team updates Sprint Backlog, Scrum Master updates Improvement Backlog

Sprint Review

■ Informal, 2-4 hours, informational, attended by all. All discuss and review

■ Only completed Items (results/functionality) are presented. New Ideas to the backlog

Sprint Retrospective ■ The whole Scrum Team. What did we

experience? What went well? What can be improved?

■ Decide, take responsibility and action

Initial Vision

More on Backlog + budget?

Sprint Planning

Daily workUpdate Sprint

Backlog

Daily Scrum

Days < Sprint length

Sprint Review

Sprint Retrospective

Done

Product Owner Responsible for vision, business value, prioritization and Product Backlog

Sprint

Yes

Yes

No

No


改改Roles – the Product Owner (PO)Roles – the Product Owner (PO) Is responsible for

Product Vision

Business Value, business objectives, return on Investment (ROI)

Prioritization – Including release or phase management, in what order to bring product features and qualities to use

Maintains and refines the Product Backlog

Gathers and develops Product Backlog Items (PBIs)

Acquires business value for PBIs in dialogue with stakeholders

Gets PBIs costs estimated – by the Team

Prioritizes PBIs on the backlog,

Presents the PBIs to the Team

Participates in the Sprint Planning meeting(s)

Selects the best possible set of PBIs for the Sprint together with the Team

Participates in the Product Backlog Refinement

Works with the Team on clarifying and decomposing relevant PBIs, trawling for acceptance criteria

Works perpetually on uncovering more domain knowledge

Participates in the Sprint Review meeting

Approves completed PBIs in the Sprint

Collects input from stakeholders, customers and users

Follows Sprint progress

Via Daily Scrum, Sprint Backlog and Scrum Master

Answers questions as they pop up during the Sprint, generally supporting the Team

A perfection of means, and confusion A perfection of means, and confusion of aims, seems to be our main of aims, seems to be our main

problem.problem.Albert EinsteinAlbert Einstein


改改Roles – the Scrum Master (SM)Roles – the Scrum Master (SM) Is a servant leader first of all, and for all

Always looking for ways to clear the road for the others

Is responsible for

The Scrum process and optimizing the Scrum environment

Removing Impediments for the Team and PO

Mentoring, coaching and supporting the Team and the PO

Ensures that meetings are held and facilitates these

Sprint Planning meetings

Product Backlog Refinement

Daily Scrum

Sprint Review meeting

Sprint Retrospective meeting

Ensures that people do what they committed to do

The Team works on the selected Backlog Items

The Team updates the Sprint Backlog (possibly Sprint Burndown)

The Product Owner cultivates the Product Backlog

That the PBIs are estimated for size

Optimizes the conditions for the Whole Scrum Team

Anything that can make the Team grow to reach their full potential

Anything enables the Product Owner to do a better job of prioritizing

Protects the Team

From interruptions and unplanned work during the Sprint

From being dragged into other work, meetings and unplanned activities

Leadership is solving problems. Leadership is solving problems. The day soldiers stop bringing you The day soldiers stop bringing you their problems is the day you have their problems is the day you have stopped leading them. They have stopped leading them. They have either lost confidence that you can either lost confidence that you can help or concluded you do not care. help or concluded you do not care.

Either case is a failure of leadership.Either case is a failure of leadership.Colin PowellColin Powell


改改Roles – the Development Team (Team)Roles – the Development Team (Team) Consists of 7 +/- 2 members

Cross/functional, all primary skills needed are in the Team (design, architect, developer, test)

Ideally 100 percent allocated and co-located

Willing to commit to the work, to each other and to the organization

Is responsible for collaboration and the work

Analyzing and designing PBIs, finding acceptance criteria and decomposing into manageable sizes

Building the Sprint Backlog of tasks

Monitoring and reporting progress and impediments

Refining and estimating size of PBIs

Self-managing within the given constraints

Authority to do whatever is necessary to meet the Sprint Commitment

Authority to manage their own space

Responsible for resolving their own conflicts

Teams create their own Team rules: Never use the words: “You did so and so”,be on time, respect the work of others, no name calling

Self-organizes during the Sprint

The Team decides who does what and when in the Sprint

All Team members attend the Daily Scrum

The Team updates the Sprint Backlog

The Team inspects and adapts as the Sprint develops

The Team committed to the Sprint, everybody else leave them to do the job

A small self-organizing team is the organizational structure most likely to

come up with innovation.Steve Denning


改改Roles – All the RestRoles – All the Rest Management

Provide resources for the initiative or project

Help setting Teams, removing impediments

Typically approves projects, budgets and plans

Input to Product Backlog

Follows progress, helps the Team if they can

Customer

Pays for the project

Provide business objectives to be fulfilled

Input to Product Backlog

Validate results and values achieved


Users

Use and validate result

Input to Product Backlog, refinements and acceptance criteria


The World

Input to Product Backlog,

Follows progress because results also matter to them, helps the Team if they can


改改Activity – the Sprint itselfActivity – the Sprint itself The Sprint must result in a Product Increment

Completely “Done”!

The Team is set free to accomplish the committed goal

Leave the Team alone, but help when asked

The Scrum Master does everything to:

Prevent unplanned work and activities in the Sprint

Protect the Team from being dragged into other work

The Team inspects and adapts during the Sprint

They find solutions to discovered challenges together

They split the work between themselves according to their best judgement

They seek necessary help from the rest of the organization

The Team provides visibility during the Sprint

They update the Sprint Backlog (possibly Sprint Burndown)

They conduct Daily Scrum to keep an eye on the Sprint Goal and plan the next day

Every day the Team looks at the Sprint Goal and assesses if it still is realistic to meet

If the Team feels that the Sprint Goal is threatened, they try to find alternative solutions that are less resource demanding or without dependencies

If still challenged they call in the Product Owner to discuss if a revised Sprint Goal and Commitment can be found, and the PO sets the expectations with Stakeholders

A Sprint can be aborted by the PO, if the Sprint Goal has become irrelevant

Backlog Refinement

Sprint R e view

Sprint Planning #1 Sprint

Ret r ospecti v e

Daily Scrum

Sprint Planning

#2


改改Activity – Sprint Planning #1Activity – Sprint Planning #1 Time-boxed 2-4 hours

The Team, the Product Owner and the ScrumMaster

The purpose is to select Items from the top of the Product Backlog for the next Sprint

The Product Owner has made sure that relevant Items are refined and estimated

The Product Owner has already prioritized the Items

The Product Owner has formulated a Sprint Goal

The Product Owner works on raising the Team’s understanding of the Items

The Team has assessed its resources and hours. i.e. they know their capacity

Estimates of Product Backlog Items may change with new discoveries

In dialogue with the Team the best possible Sprint Goal and set of Items for the Sprint is selected

This is the Selected Backlog. It is “as good as it gets” in the time box

product backlogNext

+1

+2

+3

++

Out of scope

New

Sprint Planning #1


改改Activity – Sprint Planning #2Activity – Sprint Planning #2 Time boxed: 2-4 hours

The Team and the ScrumMaster are present, the Product Owner is available for clarification

The purpose is to decide how to deliver the selected Product Backlog Items

Analysis and design is finalized for each Product Backlog Item

The Team typically decomposes Product Backlog Items into Tasks

No task should last more than 1 day, if it does, break it further down if at all possible

The Sprint Backlog is built including the expected order of execution

An initial assignment of the first Tasks to Team members is agreed to

Based on the identified Tasks a double-check of the feasibility of completing the work in the Sprint is carried out

If the Team is in doubt about the feasibility of the Sprint Goal, the Product Owner is called back and they to reack common ground

The final Sprint Backlog is made public

This is an expansion of the Sprint Goal

This represents the Team’s Sprint Commitment

This is “as good as it gets” in the time box

Sprint backlog

To do Progress Done

Sprint Planning

#2


改改Activity – The Daily ScrumActivity – The Daily Scrum Synchronization by the Team

The Team and the Scum Master participates

The event only lasts 15 minutes

Held same place, same time, every working day

Participants cannot be late!

Only the Team and ScrumMaster speak – possibly the Product Owner

The event is public

Anyone can come but may not speak

This is one of the ways the rest of the organization can follow Team progress

This is part of the transparency the Team provides

3 questions are asked to everybody

What have you accomplished since the last Daily Scrum towards the Sprint Goal?

What do you expect to accomplish until our next Daily Scrum?

Does anything prevent you from working optimally?

The ScrumMaster reports on his work

Impediments removed or in progress

Implemented improvements

Sprint backlog

To do Progress Done

DailyScrum


改改Activity – Sprint ReviewActivity – Sprint Review Time-boxed to maximum 2-4 hours

The Product Owner

The Team presents accomplishments from the finished Sprint

Product Owner must attend, Stakeholders are invited

Only finished Product Backlog Items (“Done”) are presented

Artifacts (documents) can only be used as support for real product or functionality

This is how the rest of the organization can know ”where we are” in the project

A straight forward and effective meeting

As little preparation as possible, no PowerPoint

The audience asks questions and makes comments

Looking forward

The Product Owner and Stakeholders identify things missing, slightly different than they wanted or new things they realize would be beneficial

This all goes to the Product Backlog

product backlogNext

+1

+2

+3

++

Out of scope

New

Sprint R e view


改改Activity – Sprint RetrospectiveActivity – Sprint Retrospective The Whole Scrum Team review the sprint

The Scrum Master facilitates and chooses a pattern for the Sprint Retrospective, e.g. “The six step approach”

Is everybody OK with talking openly?

Create a timeline of the Sprint

Ask – What went well?

Ask – What could be improved?

Ask – Who is in control?

Create and agree on an action list

It is all about improving the process, the throughput and the Team's pride of work

A system will always have at least one constraint

Identify the biggest impediment and try to remove that one

Make sure to take action!

Retrospectives where everybody experiences that concerns are taken care of professionally are great motivators for people

Retrospectives without real action are destructive to the Team’s motivation and performance

The Sprint Retrospective is the hub around which the whole constant improvement revolves.

Sprint backlog

To do Progress Done

Sprint Ret r ospecti v e


改改Activity – Product Backlog RefinementActivity – Product Backlog Refinement During the Sprint the Team and the Product Owner meet

for Product Backlog Refinement

If it doesn’t happen, the result is a poor Backlog, poor Sprint, loss of respect for the process, loss of motivation

One solution is to enforce a meeting

Time-boxed to maximum 2-4 hours, or maybe two meetings

The Product Owner has selected candidate Items for next Sprint

Epics (Large Items/stories) that need to be decomposed

New ideas that need to be discussed, formulated and estimated

The Team estimates the requested Product Backlog Items

There is dialogue, building of knowledge, learning

There is detailed requirement analysis, trawling for acceptance criteria

The Backlog Refinement is a precursor to Sprint Planning 1

It gives the Product Owner input to his prioritization

product backlogNext

+1

+2

+3

++

Out of scope

New

Backlog Refinement


改改Artifacts – Product IncrementArtifacts – Product Increment Each Sprint delivers a Product Increment

A set of Product Backlog Items, completely finished and of identifiable value to stakeholders

Fully verified and documented – Done!

A solid “Done-criteria” is crucial

A Product Backlog Item is “Done” when:

The specification (often a User Story) is fulfilled and can be verified

All acceptance criteria are fulfilled

All “Global Constraints” relevant for this Item are fulfilled (performance, language, usability, platforms etc.)

All engineering “Done Criteria” relevant for this Item are fulfilled

Done Criteria

Done Criteria is something the organization and the Team imposes on work in order to ensure quality

They are highly domain dependent

They could be peer-review, certain test procedures, regression testing, module testability, checklists for standard of work


改改Artifact – Product Backlog Artifact – Product Backlog The Product Backlog is an ordered list of requirements to the

product

It contains features, qualities and issues

It is often split in sections for Releases or phases and Sprints

Each entry is called a Product Backlog Item, these are often given in the form of “User Stories”

The Product Backlog must be the only driver of what theTeam works with

The Product Backlog is open and visible to all parties

Stakeholders are expected to make an effort to understand the Product Backlog

The Product Owner owns the Product Backlog

Anybody can add Items to the Product Backlog

Only the Product Owner orders and prioritizes Product backlog Items

The Product Backlog can be

Wall with Post-its, a board with cards and magnets

A spreadsheet. A dedicated IT system.

product backlogNext

+1

+2

+3

++

Out of scope

New


改改Artifact – Product or Release Burndown ChartArtifact – Product or Release Burndown Chart The Product or Release Burndown shows

macro progress

For every Sprint, record the outstanding amount of estimated work left

Often the Team's Velocity (amount of work done in a Sprint)is tracked here

Often more information is included: new or removed Product Backlog Items, re-estimates etc.

Product Burndown can be used for:

Predictions about “Estimated Time of Arrival” for fixed scope projects

Predictions about “Estimated Scope” for fixed time projects

Often the Product Owner uses the Burndown to keep Stakeholders informed, it is typically shown at Sprint Review meetings

Sometimes other forms are used

Burn-ups, process control charts

Other “Information Radiators” often used by the Product Owner

Outstanding Issues, amount of unplanned work, support etc.

6 7 8 954321

60

50

40

30

20

10

0

Velocity

Product/Release Burndown

Sprints

Remain

Ideal

Ideal

P o i n

t s

600

500

400

300

200

100

06 7 8 954321


改改Artifacts – Sprint Backlog (Improvement Backlog)Artifacts – Sprint Backlog (Improvement Backlog) The Sprint Backlog is the Team's plan for the Sprint

How to deliver the Items included in the Sprint Goal and commitment

It typically contains the Items and the Tasks, that the Team have created

The Team have planned execution in a certain order, which may change of course

The Sprint Backlog is open and visible to all parties

Stakeholders can gain insight into the progress

The Team owns the Sprint Backlog

Only the Team modifies the Sprint Backlog

The Team records unplanned and discovered work on the Sprint Backlog to provide transparency

The Sprint Backlog can be

A board with Post-its, or with cards and magnets

A spreadsheet

A dedicated IT system

The Improvement Backlog

It is good practice to keep a list of identified candidates for improvement or impediments the Team experiences

The Scrum Master maintains the Improvement Backlog and records progress and blocked items

Just making Impediments visible helps to get them removed

Sprint backlog

To do Progress Done

Improvement Backlog

Sprint backlog

To do

impediment backlog

Progress

Blocked

Unplaned

Done


改改Artifact – Sprint Burndown ChartArtifact – Sprint Burndown Chart The Sprint Burndown chart shows micro progress

For every day in the Sprint, record the outstanding amount of Tasks

The Team will use this chart, if it makes sense to them and/or gives valuable transparency to Stakeholders

Often more information is included such as new, removed or discovered Tasks

The Team uses Sprint Burndown for:

Providing transparency to Stakeholders

Assessment of whether the Sprint Goal still is achievable and plausible

Discussion of events during Retrospective

Stakeholders can follow progress here

They should not attempt micro-management through the Sprint Burndown Chart

Results are important – not a nice Sprint Burndown Chart with a straight line

Sprint Burndown

D a ys

Remaining

Ideal

T a s k s L e

f t

60

6 7 8 9

50

5

40

4

30

3

20

2

10

10


改改Artifacts – Product Backlog, the ItemsArtifacts – Product Backlog, the Items

Id

Theme

Effort with uncertainty

Other costs

Description. Typically as a

User Story

Name

When?

Whose idea?

Ref to PBI or docs

Cynefin Complexity

Business value with uncertaintyMore on the back.

TypicallyAcceptance Criteria

Kano Value

Kano user value


改改The User StoryThe User Story A Good ”User Story”

As a so-and-so user Who, role

I want to be able to do this-and-that What, functionality

In order to achieve jada-jada-jada Why, business Value

Why is it powerful?

It is simple – business people and techies understand it

It has the right size for planning purposes

It provokes communication – and learning

It provokes participatory design

States things in clear terms, not vague

Extra information to the User Stories are typically given as Acceptance Criteria

Given a-certain-context and some-more-context

When this-event occurs

Then such-an-outcome and another-outcome


改改Estimation with Planning/Estimation PokerEstimation with Planning/Estimation Poker Every Team Member has a deck of Planning Poker cards

The Product Owner explains the Product Backlog Item

The Team asks questions and discuss until understand reasonably

Everybody then show their bet at the same time to avoid anchoring of estimates

The person with the highest estimate and the one with the lowest one justifies their choices

“Why do you think this Item is so hard?”

“Why do you think this Item is so easy?”

Others chime in, information comes on the table, knowledge is revealed

This normally settles down quickly

Based on this new information The Team makes another estimate

After two or three times the Team goes with the majority or the average

Estimation is based on one or more reference or calibration Product Backlog Items

People perform comparative estimation much better than absolute estimation

Comparison provokes discussion, not just opinion

5

3

3

3

2

1

Sto r y

321

5

100Si z e

402013853210


改改Agile Manifesto: 4 values, 12 PrinciplesAgile Manifesto: 4 values, 12 Principles

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity – the art of maximizing the amount of work not done – is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

2001, Wasatch Utah

We value:We value: Individuals and interactions over processes and tools Individuals and interactions over processes and tools Working software over comprehensive documentation Working software over comprehensive documentation Customer collaboration over contract negotiation Customer collaboration over contract negotiation Responding to change over following a plan Responding to change over following a plan


改改Avoid Green-shiftingAvoid Green-shifting Reporting up the organizational

structure:

At the the top, the sun is shining, fruits are ready

Here everything looks OK and relaxed

There is a slight hint of smoke, and maybe there is a fire somewhere

Here we certainly feel the smoke, and no smoke without fire, right?

Open fire, panic and danger, abandon ship

Scott W. Ambler, 2006

“Genchi GenbutsuGenchi Genbutsu” (現地現物 ) means “go and see” and it is a key principle of the Toyota Production System. It suggests that in order to truly understand a situation, one needs to go to “GembaGemba” (現場 ) or, the “real place” - where work is done.


改改Kanban in a Nut-ShellKanban in a Nut-Shell

Visualize the workflow.

Split the work into pieces, write each item on a card and put on the wall

Use named columns to illustrate the state each item is in in the workflow

Every State has a done criteria

Limit Work In Progress (WIP)

Assign explicit limits to how many items may be in each workflow state

Manage Flow

Measure the “lead time” (average time to complete one item)

Optimize to make lead time as small and predictable as possible

Make policies explicit – Improve collaboratively

Done Done Done

Ready 4 Analyze 3 Execute 2 Verify 3 Deploy

compendium for certified scrum master and certified scrum...

Documents