Adaptive Planning (12%) Flashcards
adaptive planning
close relation to value delivery and stakeholder mgmt
better to umbrace uncertainty than to avoid it
predictive static approach:
planning is done up front
replanting is done as response to to exceptions to the plan
adaptive planning
planning is ongoing process androvidrs multiple mechanisms to proactively update the plan
iterative planning continues throughout the dev process
only planning once is not safe
we need to plan and replan
important differences to traditional planning
- trial and demonstration uncover the true requirements,which then require planning
> built a prototype and discuss it instead of planning!
- agile is less of an upfront effort and instead done throughout the project
> distribute planning efforts
- miscourse adjustments are the norm
> static, well known target/ plan once and shoot
moving target: adaptive / feedback loops to be able to adapt
Principles of agile planning
- Plan at multiple levels
- engage the team and customers in planning
- manage expectations by frequently demonstrating progress and extrapolating velocity
- tailor planning process to projects characteristics
- update the plan based on priorities
- ## use appropriate estimate ranges to reflect the level of uncertainty
agile discovery
umbrella term that refers to the evolution of agile project plans
little certainty implied by this term
progressive elaboration
rolling wave planning
process of adding more info as it emerges
at the beginning of a project we know little - would be foolish not to progressively plan
rolling wave
> idea to start with little planning and continue to plan
> progressive elaboration
> incorporate new info in the plan
this means delaying decisions to the last responsible moment
value based analysis
prioritise items according to their business value
adjust the plans accordingly
incorporate the building cost in the calculation and the
timeboxing s
time frame in which a defined set of tasks needs to be done
daily’s
retros
sprints
people start right before the deadline
timeboxing keeps the deadline close
estimate ranges
should be broad when early in the project (konfidenzintervall) and narrow at a later stage
sizing estimating and planning
1) size - how big is it
first thing: break down tasks to a size we can handle
2) estimate - how quickly can we get through it ?
3) plan - when can we do it ?
User story backlog
product backlog
refining / grooming
another name: requirement review
single and visible master list
essential for effective communication
provides essential and highly visible documentation of the project scope
sprint backlog
selection of user stories from the list
there is only 1 backlog!
grooming:
backlog constantly needs work of repriorisation and reorganization to meet customer wishes
that means to progressively add more detail, adding new work and to remove stories
po does the priorisation
relative sizing
story points
story points: main idea is to get away from estimating in hours
people are not very good in absolute estimation
therefore agile uses relative estimations
> using story points
easier to do and to understand
also: it takes away individual differences (it would take me 2 hours)
another advantage:
delivering more hours than the contract says
story point do not stress that point so much
mainly estimated in fibonacci numbers
> reduces long conversations around estimations
guidelines
- the team should own the definition of their story points
- story point estimates should be all inclusive (testing)
- point sizes should be relative
1 point / 2 point twice the size of a three point story /
- when decomposing stories the estimates do not need to sum up to the original value
- user stories do not need to be comparable overdifferent teams
affinity estimating
story point inflation
group stories in fibonacci columns so that they are comparable on size
start with old stories if available
great way of story point inflation (a tendency agile teams have to convince stakeholders of their speed )
t shirt sizing
high level estimating tool during the initiation phase of a project
supposed to be refined later on
we don’t know how much bigger m is than s
all we know is that it is bigger
story maps
high level planning tool
prioritized matrix of the features and user stories for the product start by listing features
in der spalte
features in der zu bauenden sequenz
in der zeile
1) backbone - dies muss einfach gemacht werden
2) walking skeleton
what the customer considers a minimal viable product
stories nach optionalität
3)
product roadmap
visual depiction of the product release
wideband delphi
experts estimate anonymously in order to avoid
bandwagon: topic with most interest from the group
hippo - highest paid person
groupthink - bias towards group harmony
delphi is the basis for planning poker
planning poker
fast and efficient form of estimates for stories
all the advantages of delphi
- iterative
- adaptive
- collaborative
- anonymous
not the goal to achieve precise estimates
aims teams to quickly and efficiently reach consensus on reasonable estimates
release and iteration planning
types of iterations iteration 0 development iterations iteration H 0 and H are optional in agil
spikes: timeboxed work to detect a problem
spikes
short timeboxed projects to dig deeper into a problem
architectural spike
risk based spike
fast failure
key projects fail fast in order to keep cost down
high level planning
this should be done before sprint 1
outputs of high level planning
updated backlog of user stories and risk response actions
high level (coarse grained) relative estimates for each story
a release goal
a target date for the release
product owner and sponsor should be present
release planning
sprint planning of multiple sprints
plans are usually based on the teams velocity
all stakeholders should be present
- asses prioritized backlog and review the sizing of stories
- sort the story by release
- refine initial roadmap
- slice the stories
what proportion of the backlog can be delivered in this release
how much can we get done ?
use velocity trend of the last iterations
slice the stories
breaking down stories that are too large
1) slicing compound stories
includes multiple goals that are relatively independent
2) slicing complex stories
story is sliced down so it can be worked on in 1 sprint
estimating velocity of first sprint
how much can we realistically commit to ?
that is the baseline for the velocity
iteration plannings
input updated backlog goal for the iteration 1. half po describes backlog items 2. half team breaks down selected items
- discuss user stories in backlog (user story C conversation)
- select estimated user stories from backlog
selection of user stories out customer believes are interesting and we can build
team discussed stories with PO and selects stories to build - define DoD
(user story C confirmation) - break down tasks
- estimate tasks!!!
in hours real time - in kanban this is considered waste
