Et vigtigt redskab i arbejdet med backloggen er at nedbryde store features og funktionsområder til mindre, så de fx. passer ind i en iteration eller er overskuelige at implementere for et team. Men nedbrydning handler ikke kun om en passende størrelse. Det kan også være et afgørende bidrag til effektiv prioritering og planlægning, og kan sågar mindske behovet for estimering. Nedbrydning er også et generelt princip, der med fordel kan bruges på andre og større områder end blot en enkelt backlog.

1. Bliv
en
haj
+l
nedbrydning
22.
juni
2015
Jesper
Thaning,
partner
BestBrains
AS

2. Agenda
• Produktnedbrydning
• Hvorfor
nedbryde?
• 9
metoder
+l
nedbrydning
• Es+mering?
• AHængigheder

3. DeKe
er
ikke
…
User
Story
Task
1
Task
2
Task
3
Task
4

4. GOD
PRODUKTUDVIKLING
FAST
FEEDBACK
–
SMÅT
ER
BEDRE
Nedbrydning

5. Hvordan
kan
et
produkt
nedbrydes?
Produkt
(Projekt)
Release
Feature
User
story
Acceptkriterie
Finde
værdien
og
målene
Finde
”the
Minimal
Marketable
Feature”
Finde
den
minimale
implementa+on
Finde
den
simpleste
måde
at
opfylde
et
behov
på
Finde
det
næste
”Product
Increment”
(Afgrænsning
af
projektet
–
foretræk
små
projekter)
IMPLEMENTÉR
Nedbrydning
Mål

6. User
story
Hvorfor
nedbryde
noget?
1. Prioritere
2. Småt
er
bedre
3. Afdække
aHængigheder
4. Undgå
gold
pla+ng
5. Undgå
“gidsler”
Batch
size
reduc+on
Don
Reinertsen
User
story
1
2
3

7. Hvordan
nedbryder
du
en
user
story
–
og
andre
+ng!
9
metoder
+l
nedbrydning
Produkt
(Projekt)
Release
Feature
User
story
Acceptkriterie
hKp://www.agileforall.com/2009/10/paKerns-­‐for-­‐splidng-­‐user-­‐stories/
hKp://bit.ly/PuCoC2
(Engelsk
cheat
sheet
-­‐
1
PDF)

8. Start Indtast Indsend Kvittering
Nedbrydning
Metode#1: Handlinger i en arbejdsproces
For at kunne implementere en simpel end-to-end og
putte komplicerede trin på bagefter

9. Start Indtast Indsend Kvittering
Nedbrydning
Simpel
Kompleks
Metode#2 Simpel vs. kompleks
Hvad er den simpleste version af denne funktionalitet? De
mere komplekse variationer følger efter

10. Start Indtast Indsend Kvittering
Data
Alder + køn
Email
Adresse
Navn
Nedbrydning
Metode#3 Variationer i data
Hvilke typer af data skal systemet kunne
håndtere. Hvad er den mest basale type?

11. Start Indtast Indsend Kvittering Behandling Registrering
Nedbrydning
Metode#4 Operationer
De forretningsmæssige operationer kan være spredt
over flere forskellige opgaver og roller.

12. Start Indtast Indsend Kvittering Behandling Registrering
§1
§2
§3
Nedbrydning
Metode#5: Hver enkelt forretningsregel
Eller grupper af forretningsregler der hører sammen

13. Start Indtast Indsend Kvittering Behandling Registrering
Stor
indsats
Nedbrydning
Metode#6 Stor indsats og efterfølgende
Den første user story bærer den tekniske byrde for
de efterfølgende

14. Start Indtast Indsend Kvittering Behandling Registrering
Nedbrydning
Metode#7 Input metode
Hvordan ser den simple brugergrænseflade ud? Den
mere brugervenlige og smarte?

15. Start Indtast Indsend Kvittering Behandling Registrering
2 s
20 ms
Nedbrydning
Metode#8 Ydeevne
Hvordan får vi det til at fungere?
Hvordan får vi det til at gå hurtigt?

16. Start Indtast Indsend Kvittering Behandling Registrering
PoC
Nedbrydning
Metode#9 Undersøgelse (spike) og implementation
Ved dårlig forståelse af løsning eller manglende afhængigheder.
Et nyt område enten teknisk eller forretningsmæssigt. Et Proof
Of Concept (PoC)

17. Start Indtast Indsend Kvittering Behandling Registrering
Data
Alder + køn
Email
Adresse
Navn
§1
§2
§3
Stor
indsats
PoC
2 s
20 ms
Nedbrydning – 9 teknikker
Simpel
Kompleks

18. Kombinere
metoder
I
et
User
Story
Map
Nedbrydning
-­‐ Data
-­‐ Regler
-­‐ ...
Handlinger
Detaljer
hKp://www.agileproductdesign.com/presenta+ons/user_story_mapping/index.html
hKp://bit.ly/1fiSfBm
(Quick
Reference
PDF
-­‐
2
pages)

19. HAR
VI
BRUG
FOR
ESTIMERING?

20. Det
store
dyr
i
nedbrydningen
Mul+
team
setup
-­‐
retningslinier
• Etabler
en
klar
doktrin
om
hvordan
aHængigheder
generelt
skal
håndteres
(program
level)
• Skub
beslutninger
om,
hvad
der
skal
gøres
med
de
konkrete
aHængigheder
nedad
(team
level)
• Udbyg
tværgående
kommunika+on
(team
+l
team)
• Etabler
en
klar
prioritets-­‐kæde
hele
vejen
op
+l
øverste
niveau
AFHÆNGIGHEDER
Hvad
–
Hvordan
–
Hvornår
Product
Owner
Chief
Product
Owner
Product
Manager
Product
board

21. Doktrin
omkring
aHængigheder
Hvordan
håndteres
aHængigheder
• Et
team
har
en
produktejer,
en
projektleder,
en
arkitekt
og
et
udviklingsteam
• Det
er
i
sidste
instans
teamet
som
har
et
behov,
der
har
ansvaret
for
at
anmode
om
en
funk+onalitet
hos
et
andet
team,
samt
at
beskrive
det
som
user
stories
• Det
implementerende
team
har
ansvaret
for
at
aolare
og
koordinere
omkring
funk+onalitet,
som
flere
teams
har
brug
for,
samt
at
sikre
at
langsigtede
mål
bliver
+lgodeset
• Prioriteter
afgøres
via
følgende
hierarki:
produktejer,
programchef,
programbestyrelse

22. Risici
Mister
vi
overblikket?
Jesper
Thaning
jt@bestbrains.dk