Adaptive Planning (12%)

Question 1

adaptive planning
close relation to value delivery and stakeholder mgmt

better to umbrace uncertainty than to avoid it

Answer 1

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

Question 2

Principles of agile planning

Answer 2

• 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

Question 3

agile discovery

Answer 3

umbrella term that refers to the evolution of agile project plans

little certainty implied by this term

Question 4

progressive elaboration

rolling wave planning

Answer 4

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

Question 5

value based analysis

Answer 5

prioritise items according to their business value

adjust the plans accordingly

incorporate the building cost in the calculation and the

Question 6

timeboxing s

Answer 6

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

Question 7

estimate ranges

Answer 7

should be broad when early in the project (konfidenzintervall) and narrow at a later stage

Question 8

sizing estimating and planning

Answer 8

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 ?

Question 9

User story backlog
product backlog

refining / grooming
another name: requirement review

Answer 9

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

Question 10

relative sizing

story points

Answer 10

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

Question 11

affinity estimating

story point inflation

Answer 11

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 )

Question 12

t shirt sizing

Answer 12

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

Question 13

story maps

Answer 13

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)

Question 14

product roadmap

Answer 14

visual depiction of the product release

Question 15

wideband delphi

Answer 15

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

Question 16

planning poker

Answer 16

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

Question 17

release and iteration planning

Answer 17

types of iterations 
iteration 0
development iterations 
iteration H
0 and H are optional in agil 

spikes: timeboxed work to detect a problem

Question 18

spikes

Answer 18

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

Question 19

high level planning

Answer 19

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

Question 20

release planning

sprint planning of multiple sprints

plans are usually based on the teams velocity

Answer 20

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

Question 21

estimating velocity of first sprint

Answer 21

how much can we realistically commit to ?

that is the baseline for the velocity

Question 22

iteration plannings

Answer 22

input 
updated backlog 
goal for the iteration 
1. half
po describes backlog items 
2. half 
team breaks down selected items 

1. discuss user stories in backlog (user story C conversation)
2. 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
3. define DoD
   (user story C confirmation)
4. break down tasks
5. estimate tasks!!!
   in hours real time - in kanban this is considered waste