Compendium Compendium for Certified Scrum Master and for Certified Scrum Master and Certified Scrum Product Owner Certified Scrum Product Owner 改 ScrumMaster.dk – ScrumMaster.dk – 舎 AgileLeanHouse A/S AgileLeanHouse A/S
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]
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.
Core Scrum Compendium 22.0
改改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 pro- cess 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
Core Scrum Compendium 32.0
改改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?
Core Scrum Compendium 42.0
改改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?
Core Scrum Compendium 52.0
改改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
Core Scrum Compendium 62.0
改改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
Core Scrum Compendium 72.0
改改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
Core Scrum Compendium 82.0
改改The Scrum Flow – Odd-eThe Scrum Flow – Odd-e
http://scrumprimer.org/anime
Core Scrum Compendium 92.0
改改The Scrum Flow – Schwaber & SutherlandThe Scrum Flow – Schwaber & Sutherland
Core Scrum Compendium 102.0
改改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
Core Scrum Compendium 112.0
改改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
Core Scrum Compendium 122.0
改改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
Core Scrum Compendium 132.0
改改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
Core Scrum Compendium 142.0
改改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
Follows progress, helps the Team if they can
Users
Use and validate result
Input to Product Backlog, refinements and acceptance criteria
Follows progress, helps the Team if they can
The World
Input to Product Backlog,
Follows progress because results also matter to them, helps the Team if they can
Core Scrum Compendium 152.0
改改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
Core Scrum Compendium 162.0
改改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
Core Scrum Compendium 172.0
改改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
Core Scrum Compendium 182.0
改改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
Core Scrum Compendium 192.0
改改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
Core Scrum Compendium 202.0
改改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
Core Scrum Compendium 212.0
改改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
Core Scrum Compendium 222.0
改改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
Core Scrum Compendium 232.0
改改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
Core Scrum Compendium 242.0
改改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
Core Scrum Compendium 252.0
改改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
Core Scrum Compendium 262.0
改改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
Core Scrum Compendium 272.0
改改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
Core Scrum Compendium 282.0
改改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
Core Scrum Compendium 292.0
改改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
Core Scrum Compendium 302.0
改改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
Core Scrum Compendium 312.0
改改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.
Core Scrum Compendium 322.0
改改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