2020-01-20

Linköpings universitet 1

TDP029En agil systemutvecklingsprocess –Sprint 0Annika SilvervargCOIN/HCCS/IDA

Sprint 0• (Strategic intake & research)

• (Product statement)

• (Design koncept)

• Technical solution outline

• Practical agreements

• Setting up the ”room”

• Definition of done

• Start on Product backlog

Strategic intake & research• Market and end-user

– Competition?

– Market?

– End-users?

• Brand

– Defined brand?

– ”tone-of-voice”?

– Corporate visual identity?

Product statement• Template: For (target customer) who (statement of need or

opportunity) the (product name) is a (product category) that(key benefit, compelling reason to buy)

• Example: trakz.nl is a trustworthy online music store, we arepersonal and passionate about music!

Design koncept• Graphic profile

• Conceptual design

• Fråga kunden om sådan finns

– Om inte, diskutera hur det ska hanteras!

Technical solution outline• Can include

– legacy system limitations

– CMS characteristics

– Database

– GUI

– Architecture

– …

• Viktigt att diskutera detta med kunden!

• Kan behövas ytterligare en iteration för detta!

1 2

3 4

6 7

2020-01-20

Linköpings universitet 2

Practical agrement• When do you work?

• Where do you work?

• What are the responsibilities of the scrum master?

• Contact information, e-mail, phonenumbers….

• When do you have stand-up meetings (and how)?

• When do you demo and test and with whom?

• When and how do you do the retrospective?

• Viktigt att göra detta explicit inom gruppen!

• Viktigt att komma överens tillsammans med kunden om vad som gäller för demo/test!

Setting up the ”room”• Hardware

• The room

• Supplies

• Software

– Dropbox

– GITLab, SVN,…

• Scrumboard

• Physical, Trello, wiki, excel, google docs,…

• Detta KAN läggas på scrum mastern, men också någon/några andra

Definition of Done• Technical requirements

– Devices?

– Browsers?

– Documentation?

– How tested?

• User experience

– How does it feel?

– Tests with external people?

• Customer acceptance

– Who decides when done is done?

• Viktigt att diskutera detta med kunden!

Start on product backlog• The backlog is a prioritized features list, containing short

descriptions of all functionality desired in the product, typically in the form of

• User stories, which are short, simple descriptions of the desired functionality told from perspective of the user categories:

– As a site visitor, I can access old news that is no longer on the home page, so I can access things I remember from the past or that others mention to me.

– As a site editor, I can set the following dates on a news item: Start Publishing Date, Old News Date, Stop Publishing Date so articles are published on and through appropriate dates. These dates refer to the date an item becomes visible on the site (perhaps next Monday), the date it stops appearing on the home page, and the date it is removed from the site (which may be never).

User story templateTitle (one line describing the story)

As a [role]I want [user need]So that/because [resulting ability] OR

Alt

As a [role]I can [do/view something]

User story exempel

8 9

10 11

12 13

2020-01-20

Linköpings universitet 3

Acceptance test template• Scenario 1: Title

• Narrative:Given [context] (And [some more context]...)When [event]Then [outcome] (And [another outcome]...)

Acceptance test exampleUser story Criteria for acceptance test

User stories types• Epics

• Back-end

• Technical

– Infrastructure

– Refactoring

– Bug fixes

– Spikes

• Non functional

– UX

– Safety, Security, Performance

– Sustainability

A good user story – INVEST• Independent, of other stories

• Negotiable, not a contract

• Valuable, to customer or end user

• Estimable, enough information and reasonable scope

• Small, coded and tested within half a day to two weeks

• Testable, clear definition of ”done”

Sprint 0 – Att Göra• Grupp: Utse en scrum master.

• Grupp: Gå igenom scheman och gör en detaljerad planering för vilka tider gruppen ska jobba. Bestäm ett lämpligt straff för sen ankomst (t.ex. bjuda gruppen på fika).

• Scrum master: Välj en lämplig yta på en stor whiteboard och rita upp en scrumboard eller sätt upp en digital samarbetsyta, t ex Trello eller Jira.

• Grupp: Se till att ett möte med kunden äger rum. Utbyt kontaktuppgifter och kom överens med kunden om hur kommunikationen under projektet ska fungera.

• Kund: Delta i möte med projektgruppen och gör en översiktlig beskrivning av det planerade systemet (inklusive syfte, vision, etc).

• Kund och Grupp: Kom överens om och skriv under avtal.

• Kund: Förbered user stories och förmedla till projektgruppen.

• Grupp: Genomför en tekniköversikt och riskanalys gällande val av teknikplattformar (utvecklingsverktyg, programspråk, databashanterar, etc).

Avtal

20

• Finns på hemsidan

• Ägande och nyttjanderätt

• Sekretess

• Maila mig en kopia (behöver inte vara underskriven)

15 16

17 18

19 20

2020-01-20

Linköpings universitet 4

Tidsplan och gemensamma övningar

21

v4-5 Sprint 0

• v4 To Fö + Övning Extreme hour

• v5 To Product backlog från kund klar

• v5 Fr Övning Planning poker, Genomgång och diskussion inför Sprint 1

TDP029En agil systemutvecklingsprocess –Sprint 1 ->Annika SilvervargCOIN/HCCS/IDA

Sprint 1-6• Release plan – Product backlog

• Iteration plan – Sprint backlog

• Scrum board och Burn down chart

• Dagliga scrum-möten

• XP praktiker för programmering

• Demo och Acceptance testning

• Retrospective

Planering

25

• Release plan

– Vad ska vara klart och när?

• Iteration plan

– Vad ska vi göra härnäst?

Release plan – Product backlog

26

• Kund specar funktioner (user stories i Product backlog)

• Kund kan ev uppskatta viktighet

• Utvecklare kan föreslå funktioner (user stories)

• Utvecklare uppskattar tid för utveckling av user storiesMax 3? dagar annars dela upp!

• Utvecklare kan ev uppskatta teknisk svårighet

• Utvecklare anger tidsramar (för hela projekttiden alt första perioden dvs 3 iterationer)

• Kund väljer funktioner (release plan)

Tidsuppskattning av user stories• Intuitiva tidsestimat – Hur lång tid skulle det ta om jag fick

programmera utan att bli störd? Jämför olika stories med varandra

• Spike – Prova att implementera en liten del för att få en idé om ungefär hur ett problem kan lösas (kan behöva göra detta iSprint 0/1 innan ni kan estimera resternade stories)

• Estimera genom jämförelse – jämför med tidigareimplementerade stories (kan göras i senare iterationer)

• Estimera genom planning poker

21 23

24 25

26 27

2020-01-20

Linköpings universitet 5

Planning poker Iteration plan – Sprint backlog

29

• Utvecklare bryter ner user stories i product backlog till tasksMax 8? h Annars bryt ned!

• Utvecklare uppdaterar ev tidsestimat för user stories

• Utvecklare anger tidsramar för iterationen

• Kunden väljer och ev prioiriterar user stories (och tillhörande tasks) till iterationen

Tidsramar – Release (hela projektet)

30

Mantid:

• ”Programmeringsenheter” * Dagar i iteration * Iterationer(par/individer/grupper)

• Ex: 3 par * 3 dagar * 6 iterationer = 54 dagar

Ostörd tid:

• Velocity * Mantid

• Ex: 75% * 54 dagar = 40 dagar

Velocity är hur stor andel av mantiden som faktiskt läggs på programmering (exkluderar t ex möten, research etc)

Tidsramar – Iteration

31

Mantimmar:

• ”Programmeringsenheter” * Timmar i iterationen(par/individer/grupper)

• Ex: 3 par * 24 h = 72 h

Ostörd tid:

• Velocity * Mantimmar

• Ex: 50% * 72 dagar = 36 h

Velocity beräkning• Första iterationen kan den vara 50%

• Andra iterationen beräknas den på hur mycket som blev gjortden första iterationen:

– Uppskattad tid för avklarade tasks/Mantimmar

– Ex: 0 h / 72h = 0%

– Ex 108 h /72 h = 150 %

– Ex: 44 h / 72h = 75%

SCRUM Board

28 29

30 31

32 33

2020-01-20

Linköpings universitet 6

Exempel med Trello

34

Burn-down chart

35

Scrum möten

36

Sedan sist har jag gjort …

Nu ska jag göra …

Jag har problem med ….

XP praktiker

37

• Par programmering

• Enhetstest*

• Kodstandard*

• Koda “enkelt”

• Be kund om klargöranden

• Omstrukturering vid behov

• Kontinuerlig integrering + testning*

• Hållbart arbetstempo (anpassa scope vid behov)

* Stäm av med kund

Demo och Acceptance testning• Kort presentation av iterationen, t ex ev förutsättningar,

problem, begräsningar

• Låt kunden testa förutsättningslöst

• Diskutera ev beslut som fattats

• Kunden avgör om user stories är klara

– Om en user stor inte är klar kan den förtydligas och/eller skriva en ny user story

– Ev buggar resulterar också i nya user stories

• Avslutande diskussion om de viktigaste aspekterna

Retrospective• ”Inspect and adapt”

• Alla gruppmedlemmar skriver ned positiva och negativa saker

• Gruppen går igenom alla saker

• Gruppen bestämmer max 3 saker att förbättra i nästa iteration

• Scrum mastern följer upp vid nästa retrospective

34 35

36 37

38 39

2020-01-20

Linköpings universitet 7

Retrospective Sprintblankett• Lämnas in efter Sprin1-6

• Velocity är för den avklarade sprinten

• Delta är ca 3 negativa sakerni vill förbättra

• + är ca 3 positiva saker

Tidsplan och gemensamma övningar

42

• V4-5 Sprint 0

• V4 To Övning Extreme hour

• V5 To Product backlog från kund klar

• V5 Fr Övning Planning poker, Genomgång och diskussion inför Sprint 1

• V6-7 Sprint 1

• V7 Fr kl 10-11 Demo med kund, kl 11-12 Retrospective i Studio

40 41

42