によって Alex Ostreiko 3年前.
464
もっと見る
disciplined implementation
rules of Scrum
flexible enough to apply to most organizations
the organization must be committed
probability & impact value
multiply 2 factors
impact of occurrence
probability of occurrence
standardized steps
identify, evaluate, respond
Update requirements to reflect change
regular interactions with the Customer (stakeholders)
portfolio/program management respond to Change Requests generated by Scrum Projects
short Sprints
stakeholders' needs always change during project
principles
transparency-->inspection-->adaptation
make errors visible
full lifecycle every Sprint
acceptance tests every iteration
Acceptance Test Driven Development
Team has perspective & ownership of entire product to the Customer
how long to release
test & know all stages
same Team does all testing
we are delivering a product, not a task
value based thinking
update Product Backlog with new requirements
communication with stakeholders
stakeholders make better decisions
reduce gap between customer expectations & project deliverables
reflect changes in the external business environment
Business Agility
rapid response
transparency, inspection, adaptation cycles
change direction as needed
act in the moment
not part of Scrum Framework
Product Owner's responsibility for Profit & Loss
associated empowerment
Rules
Events
Roles
Scrum Teams
everything is a product
projects vs products
Chaotic Domain?
Transparency imperative
available to all stakeholders
Cone of Uncertainty
more of a selling prop than a useful graph
projections
do not replace empiricism
cumulative flow
Burn-up
Burn-down
updates projections
manages its progress
track likelihood of achieving SG
every Standup
compare unfinished work at the end of Sprint with last Sprint
aspect of transparency & inspection
lack of transparency
decreased collaboration
decreased communication
diminished value
increased risk
flawed decisions
ensures informed decisions
decisions made by Scrum Team
distributed project management
decision making power delegated to all members
based on perceived state of artifacts
control risk
optimize value
requirements for empirical process control
everyone who does work on the Sprint Backlog Items
Only Dev Team can change Sprint Backlog
highly visible, real-time picture of Dev Team's work
Dev Team adds work to SB as required to achieve SG
Adjusted by Dev Team as their understanding of what's needed to achieve Sprint Goal grows
track at least every Daily Scrum
remaining work can always be summed
estimates of remaining work are continuously updated
detailed enough for changes to be understood in Daily Scrum
plan to realize Sprint Goal
plan to deliver the product increment
PBIs selected for Sprint during Sprint Planning
SBIs for the first days of a new Sprint are decomposed to units of one day or less
work needed to deliver functionality as "Done"
solely owned by Dev Team
functionality in next increment
higher items more clear & detailed
allows for more precise estimates
attributes/states
"Ready"
agreed depth/level of description
between Dev Team & PO
other
e.g. group items by the Scrum Team
value
estimate
order
description
types
fixes
enhancements
requirements
funcitons
make Product Backlog
may delegate these tasks to Dev Team, but remain accountable/responsible
show what the Scrum Team will work on next
understood
transparent
visible
Optimize the value of the work performed by the Development Team
Order the PBIs to best achieve goals & missions
e.g. ROI or value
Express Product Backlog Items clearly
Stakeholders & Scrum Team must easily understand
Prepare for upcoming Sprint
Items must be deemed "Ready"
each item intended for next Sprint must be refined to the degree that it can be reasonably "Done" next Sprint
Story Sizing
Relative Business Value
historic truths vs prophetic suppositions
Other Projects
possibility to equate business value points to revenue using historic metrics
some limited scenarios only
ratio of average man-hours to story points by the same team for one Sprint
predict how much is left
estimate actual costs
story points aren't comparable between different projects
divergence
reveal symptom of another problem
do the cosmetic tasks possess higher value?
no
communication/organizational problem?
should not be scheduled first
yes
should have been factored in earlier
discrepancies may expose bias
e.g. cosmetic tasks may score low points, but higher priority
advantage
quantify ROI
highlight discrepancies & expose bias
e.g. death march
maximize value
Scrum Team receive feedback
customer
helps Product Owner to maximize value
continuously looks for value
analyses work weekly
track points weekly
even mid-Sprint?
points drop
value delivered first
estimate velocity
flat or increased as team gels
point estimates done by customer
assign business value points to each story
value points
Indications of value on Product Backlog are useful but are only a prediction until validated against users and market.
It is a good practice, keeping in mind that market reception is the best measure of value.
Dev Team & PO
PO can help to select trade-offs
people who do the work do the estimates
Dev Team responsible for all estimates
review & revise items
acquire a degree of transparency
Scrum Team decides when and how
ongoing process
never complete
evolves with the product & environment
business terms
Dev Team will translate into system terms during Sprint Planning & Refinement
can make changes any time
ordering
availability
content
Only in the Indian Scrum, in regular Scrum there is only one Product Owner
Multiple Scrum Teams
the project produces "the collaborative benefits" for the stakeholders
customers, users, sponsors
engaging stakeholders
persuasion
adopt a new perspective
requires effort
form of a sale
Maintaining business justification
outward
a favourable business perspective
image
inward
features
Reception of a product is often a matter of marketing.
can a consultant do that?
not from the client
must be from the performing organization
doesn't need to understand the technology, just the business
may represent a committee
compare with amount of work remaining after previous Sprint
velocity
transparent to all stakeholders
at least every Sprint Review
Receive requirements from the Customer
Voice of the Customer
Flexibility
stakeholder confidence
Deliver value/results early
possibly because traditionally management is something done to teams, so the management positions are assumed to be outside the team
by placing them in the PB
full-time employment recommended
increments
always work in product-based way
systems, projects, etc. are all viewed as Product
manage itself
tracking Sprint Backlog at least every Daily Scrum
refine Product Backlog
on behalf of PO
consume < 10% of capacity of Dev Team
manage Sprint Backlog
work in SB can be summed up at any time
deliver PBIs
estimates in the Product Backlog
the Increment
definition of "Done"
Specific titles are good for production environment. In development there are too many unknowns to overlook increases in responsiveness and agility afforded by increased communication and idea exchange that results from all team members sharing the same goal and responsibility.
Role based configuration works in the military and in production. Wherever the labour is heuristic, as opposed to algorithmic, and creativity is a job requirement, value based mindset produces the most efficient teams. Value based thinking unites the team members in striving to add value to the product/business, to achieve a common goal.
no sub-teams
all members have the same role
different roles
prevent value based approaches
segment focus
promote different goals
value-based vs role-based thinking
equally responsible/determined to deliver product
e.g. designer/quality inspector/team leader
aligned with the goal of the project
can exercise decision making power in managing themselves because aligned w/SG
find their way instead of receiving orders
manage themselves
jointly accountable & responsible for the delivery of every task
people don't own assigned tasks
tasks are owned by the whole team
do not change members during Sprint
application area experts
3-9 people
can be on Dev Team
when executing items from the Sprint Backlog
help those outside the Scrum Team
understand which interactions are helpful
change interactions to maximize value created by the Scrum Team
help/work with Scrum team & the organization
involves
change management
convincing
learning
understand and practice agility
increase transparency of artifacts
help Scrum Team
facilitate Scrum events as requested/needed
understand the need for clear & concise PBIs
help Dev Team
coach Dev Team till Scrum fully adopted/understood
remove impediments
create high value products
add to value by applying Scrum
self-organization & cross-functionality
help Product Owner
Facilitating related events
Communicating information
Understand & practice agility
Arrange PBIs to maximize value
Product planning in an empirical environment
Find techniques for effective Product Backlog management
to detect incomplete transparency
detect discrepancy in expected & factual results
listen closely to communications
sense patterns
inspect artifacts
apply practices to cope w/incomplete transparency
continuously work to increase transparency of the Artifacts
ensure complete transparency
Scrum Team & others
still is a management position
manages the Scrum process, not the Scrum Team
more of a role than a position
clear impediments
doesn't need to understand the architecture
only count people who execute PBIs
Scaled Scrum for larger groups
Regardless of how many sub-Scrums there are, there is only one Product Owner
6-10 members
unofficial Scrum (Indian)
frequency depends on
level of complexity
size of project
inter-team dependency
holonic?
productivity
creativity
flexibility
no need for outside assistance
Other properties still present
e.g. Standup, "Done", etc.
There may be not enough Agile culture to start with User Stories?
Scrum Team forming
not enough value based thinking yet?
incomplete Stories
re-estimate frequently
Incomplete work depreciates quickly
Re-estimate incomplete SBIs, put them back in the PB
Still do Sprint Review on the completed PBIs
when SG becomes obsolete
Only by Product Owner
otherwise redo Sprint Planning, and create a new Sprint Goal
New Sprint starts immediately when previous Sprint ends
Sprints are like projects with
flexible plan of work & product
design
definition of what will be built
Sprints are like calendar months - we can't/don't want to add days to a month
use to measure KPIs e.g. velocity
more work than 1 month?
change definition of what will be built
standard for each product
dictates how work should be done on this particular system/product
use company's conventions as starting point
define for every product
ensures artifact transparency
shared understanding
adapted at Sprint Retrospect
managed by the Dev Team
Dev Team defines "Done" for Scrum Team
guides Dev Team during Sprint Planning
how many PBIs to select for Sprint
allows to quantify work
not Acceptance Criteria
Acceptance Criteria can form basis of new stories
Acceptance Criteria apply to specific items
"Done" applies globally
used to assess when work on increment is complete
same requirements for individual PBIs?
Acceptance Criteria
Release
Retrospect Project
Review & Retrospect
Retrospect Sprint
Demonstrate and Validate Sprint
Convene Scrum of Scrums
Implement
Groom Prioritized Product Backlog
Conduct Daily Standup
Create Deliverables
Plan & Estimate
Estimate Tasks
Create Tasks
Approve, Estimate and Commit User Stories
Create User Stories
Initiate
Conduct Release Planning
Create Prioritized Product Backlog
Develop Epics
Form Development Team
Identify Scrum Master and Stakeholders
Create Project Vision
Business Justification
Processes can accommodate change in business justification
Value-driven Delivery
Help key decision makers understand the business need for a change or a product
Can be any other coherence as long as it causes Dev Team to work together, rather than on separate initiatives
Selected PBIs deliver a coherent function
Gives the Dev Team flexibility in functionality to implement
Guides the Dev Team as to why it's building the increment
crafted by entire Scrum Team
after the Dev Team chose the PBIs at the Sprint Planning meeting
Objective to accomplish by building PBIs in the Sprint timebox
Sprint lifecycle changes
Sprint Backlog may be re-negotiated
cancelled only when Sprint Goal becomes obsolete
Sprint is designed to implement new functionality
therefore Sprints where the customer is not involved are prohibited
redundant w/Continuous Deployment
refactoring
code review
no ad hoc meetings
interrupted work
unprepared participants
are
fixed objectives
predefined meetings
designed to promote
adaptation
regularity
inspection
critical transparency
is a container for
maintenance of product Backlog
development effort
the 4 events
Sprint Retrospective
inspect Sprint process in regard to
tools
process
relationships
people
adapt definition of "Done"
to increase product quality
identify potential improvements
identify & order major items that went well
accountable for Scrum process
participates as peer
encourages to improve the dev process
within the Scrum process framework
teaches to timebox
ensures the event takes place
ensures purpose is understood
formal opportunity for improvement
review (inspect/adapt) the Sprint process
focus on inspection & adaption
boyscout rule
internal meeting
entire Scrum Team
3 hrs timebox
Dev Team demonstrates outcome of Sprint
Scrum Team and stakeholders
collaborate to optimize value
result
Product Backlog may also be adjusted to meet new opportunities
revised Product Backlog w/probable PBIs for next Sprint
Assesses overall project progress
can do it more often than every SR
Accepts PBIs
purpose
adapt Product Backlog
inspect increment
Development Work
Dev Team implements functionality & technology to satisfy the Sprint Goal
if that results in unexpected work
collaborate w/PO to negotiate the scope of Sprint Backlog within the Sprint
Daily Scrum
function
key Inspect & Adapt meeting
improve Dev Team's knowledge
highlight and promote quick decision-making
identify impediments/risks
eliminate other meetings
improve communications
optimizes probability that the Dev Team meet the SG
Scrum Master
enforces rule that only Dev Team members participate
pigs & chickens
ensures that Dev Team has the meeting
teaches Dev Team to timebox Daily Scrum to 15 min
DevTeam
Inspect the work since last Daily Scrum
inspect how progress is trending
inspect progress
Synchronize activities
meet after to have more detailed discussions
Parking Lot
must understand how it intends to work together today as a self-organizing team to meet SG
Conducts the Daily Scrum
Forecast work to be done before the next Daily Scrum
Make plan for the next 24 hours
3 questions
what impediments prevent me from helping the Dev Team meet Sprint Goal?
what will I do today to help the Dev Team meet Sprint Goal?
what did I do yesterday that helped the Dev Team meet Sprint Goal?
15 minutes
regardless of size
Sprint Planning
inputs
Past performance of the Dev Team
perhaps should be of the Scrum Team
Projected Capacity of the Dev Team
Velocity
Latest Product Increment
results from previous Sprint Review & Retrospective
participation
First days decomposed into units of 1 day or less
Should be able to explain to PO & SM how it will self-organize to accomplish SG
Self-organizes to undertake the work
collective responsibility & ownership of work
e.g. individuals volunteer to do work
Receives sufficient data from the Scrum Team during Sprint Planning to forecast amount of work it can get "Done"
Design System and Work to convert PB into a working product
Create Sprint Backlog
PBIs + plan how to "do" them
Invite other people to provide advice
Renegotiate the PBIs with Product Owner
Choose # of PBIs
estimate their own productivity
select individual PBIs as well
e.g. if too much work
How to turn selected PBIs into a "Done" increment by the end of Sprint?
Product Owner
PBIs that will achieve Sprint Goal
make trade-offs
clarify requirements
discuss Sprint Goal (business objective)
Entire Scrum Team
designs the work into Sprint Backlog
inspects work from the PBIs
crafts Sprint Goal
Dev Team
select PBIs
Assess what it can accomplish
Forecast functionality that will be developed in the Sprint
the hypothesis
Scrum Master makes sure
attendants understand purpose
event
timeboxed
teach Scrum Team to timebox
happens
answer
Why is the Dev Team building the increment?
Sprint Goal
How will the work needed to deliver the increment be achieved?
What increment of work can be delivered in the timebox of the Sprint?
< 8hrs for 1 month Sprints
Sprint
Retrospect Sprint Meeting
discuss how to improve process & performance
Sprint Review Meeting
Product Owner accepts the Deliverables based on Acceptance Criteria (Done)
Demo the Deliverables to Product Owner & relevant stakeholders
Daily Standup Meetings
highly focused
short
Sprint Planning Meeting (Iteration Meeting)
High priority User Stories considered for inclusion in Sprint Backlog
Create potentially shippable Deliverables or product increments
1 - 6 weeks
Product Owner creates Prioritized Product Backlog
in the form of User Stories
prioritized list of business and project requirements
Stakeholder Meeting
Create Project Vision Statement
Study Project Business Case
Appropriation
Adapt technology to serve custom ends
Articulation
Partition work into units, divide between members, & reintegrate it into a finished product
Awareness
aware of each other's work
Requires healthy communication
Bus number
Standup meetings are a collaboration tool
e.g. a team might shift resources to help a member
fewer change requests
fast risk identification
continuous improvement
e.g. Scrum Master improves on the team based on the Sprint Retrospect
formal & informal communication
trust
high bandwidth communication
problems fixed on the spot
questions answered quickly
collaboration is everyone contributes to each feature of the final product
cooperation is sum of everyone's work
create regularity
minimize need for other meetings
skipping events reduces transparency
designed to enable critical transparency and inspection
Cadence
events
Sprints
Standups
Sprint Meetings
Sprint Review Meetings
events end when purpose of event achieved
reduce "waste in the process"?
a nod to Lean?
Sprint duration is fixed & cannot change once Sprint started
PERT compatible
Burn-down, etc.
Critical path always visible
Contain risks and complexity
Limits cost
Predictability
quantifies processes
e.g. Velocity
customer knows when feedback will be required
timeboxing ensures inspection & adaptation of process
Project Management responsibilities are distributed among the 3 roles
management and specialist efforts are not separated
team needs pm skills, but not a pm
team buy-in
there is no such subset of the project team that is responsible for project management while others are only responsible for specialist activities
Scrum Team chooses how to best accomplish their work
Approve, Estimate & Commit User Stories
Scrum Team has all competencies to produce a releasable, Done product
value based thinking, not role based thinking
own entire product as negotiated with the Customer
no separate test team
towards given goals
within boundaries
systematic use of evidence outperforms expert-only judgement
all knowledge intensive domains & complex activities
education
criminal justice
social care
medical practice
suboptimal care
preferring personal beliefs & conventional wisdom to research
reliance on experts' assumptions
not using existing research and data
Lack of systematic sharing
feedback less valued
transparency
manage risk to patient health
Evidence Based Medicine
Empirical Process Control Theory or empiricism
Get the cook in the kitchen
Each event is formal opportunity to inspect & adapt
iterative delivery
(potentially) shippable product each iteration
no need to adjust scope because this iteration of the product is complete
next version of a complete product
adapt product definition
adjust process or material being processed
adjustment must be made ASAP to avoid further deviation
if inspector determines aspects deviating outside acceptable limits & resulting product is unacceptable
empirical process control
development is too complex to rely on canned procedures
production vs development
monitor the relative efficacy of management & development practices
material for analysis during Adaptation
best when done by inspectors at the point of work
Scrum users frequently inspect
doesn't get in the way of work
progress toward Sprint Goal
detect undesireable variances
artifacts
inspection of the Deliverables by the Product Owner
continuous customer feedback
necessary to do Inspection
Information Radiators
Sprint Burndown Chart
shared Scrumboard
Meetings
Sprint Review
Daily Standups
Artifacts
Release Planning Schedule
Project Vision
Product Backlog
common standard for the aspects of the process that must be visible to those responsible for the outcome
e.g.
definition of "Done" shared by those who work & those who accept work
common language referring to the process shared by all participants
observers must have a common understanding of what is being seen
collaboration & communication between the Scrum Team members
