scrum voor gevorderde

**De 4 voordelen van Scrum**

* **Zichtbaarheid van werk**
* **Aanpassingsvermogen**
* **Gerealiseerde waarde**
* **Risico**

**Zichtbaarheid van werk**

* Scrumteams maken al hun werk transparant op backlogs
* Hierdoor wordt kennis met iedereen gedeeld en kan iedereen de voortgang zien


* Traditionele projecten zijn vooral transparant bij start en einde 
* Zichtbaarheid op resultaten tijdens project is minimaal

**Aanpassingsvermogen**

* Scrumteams gaan ervan uit dat verandering de enige constante is
* Het gebruik van feedbackloops zoals de review, retrospective en daily stand-up zorgt ervoor dat het team altijd aanpassingen maakt


* Traditionele projecten zijn heel flexibel bij de start, maar niet meer naar het einde toe

**Gerealiseerde waarde**

* Scrum projecten leveren de meest waardevolle onderdelen eerst op  (of met de meeste waarde voor de klant). Daardoor blijft de gerealiseerde waarde hoog.


* Traditionele projecten leveren pas op het einde op. De klant merkt de waarde ook pas dan op. 

\n

**Risico**

* Doordat Scrumteams resultaten in delen opleveren, wordt het risico op falen kleiner


* Bij traditionele projecten kan je lang werken aan producten die uiteindelijk niet blijken aan te slaan. Daardoor ligt het risico hoog. 

\n

**Traditionele projecten zijn tijdgedreven**

* Project manager en klant spreken eerst samen de benodigde ontwikkel- of doorlooptijd af om tot een gewenst eindresultaat te komen
* Scope mag niet meer wijzigen, maar vertragingen worden ingecalculeerd
* Inzet van mensen en middelen wordt met behulp van uurtarieven en prijzen omgerekend naar kosten

**Het probleem met deze aanpak?**

* Je scope neemt altijd toe, omdat de vragen van je klant wijzigen of bepaalde onderdelen van het product niet haalbaar blijken binnen tijd en budget. Dit brengt klant én opdrachtgever in gevaar: wie pakt het risico?
* Tijdsinschattingen zijn niet altijd betrouwbaar, zelfs met vertragingen ingecalculeerd (denk aan de wet van Parkinson!)

\

**Scrumprojecten zijn waardegedreven**

* Je garandeert je klant dat je binnen een afgesproken tijd en budget een project of product oplevert dat gebruiksklaar is en waarde genoeg heeft voor je klant
* Dringende en belangrijke items werk je eerst af 
* De opdrachtgever kan tussentijds bijsturen 
* Al na enkele sprints hebben agile projecten een reële planning, door beter prioriteiten te stellen

**Waarom moet je projectdoelen definiëren?**

Een **projectdoel** geeft de reden van al je inspanningen aan: wat wil je met je project bereiken?

Een goed projectdoel geeft ook altijd het verschil aan tussen de huidige situatie en de gewenste situatie.

Een **projectresultaat** geeft aan welk product (of dienst) jouw team concreet zal opleveren.

**Voorbeeld projectdoel vs. resultaat**

Bedrijfsdoel Coca-Cola (management): 

Duurzame, winstgevende groei wereldwijd.

Projectdoel (opdrachtgever): 

We willen het marktaandeel van Coca-Cola Zero in België met 5% vergroten.

Projectresultaat (projectteam): 

Een reclamecampagne bestaande uit een 30 seconden durende Belgische televisiecommercial van HD-kwaliteit voor Coca-Cola Zero.

**Maak je projectdoelen SMART**

* Specifiek: grondig omschreven, met voldoende details
* Meetbaar: achteraf moet je kunnen meten of het doel gehaald is (in tijd, kost, kwaliteit ...)
* Acceptabel: wie is verantwoordelijk voor het te behalen doel?
* Realistisch: je doel moet haalbaar en uitvoerbaar zijn
* Tijdsgebonden: er staat een einddatum op

**Stakeholderanalyse**

* Breng eerst al je stakeholders in kaart:
* extern én intern, klanten én anderen 
* heel betrokken vs. niet betrokken 

**Invloed (power) -** \n **Belang (interest)**

**matrix**

Zoek de conflicterende belangen tussen stakeholders

**Priority-** \n **involvement**

**matrix**

Bekijk hoe je best op deze wensen kan inspelen en iedereen op één lijn krijgt

**Persona’s kunnen je klant helpen definiëren**

* Een persona is een een zeer gedetailleerde omschrijving van de gebruiker van jouw product of dienst
* Je gaat bij de omschrijving van een persona niet enkel op zoek naar wat mensen scheidt van elkaar (zoals geslacht, leeftijd, woonplaats) maar ook wat hen bindt (waarden, normen, emoties, drijfveren).
* Deze bevindingen pen je neer in één of meerdere profielen die je ophangt in de werkruimte

**Buyers vs. user persona’s**

* In een **buyer persona** omschrijf je de **ideale klant**. Een buyer persona helpt je om online marketing en sales effectiever te laten werken.
* Een **user persona** is een omschrijving van een **gebruiker van een product of dienst**. Dit hoeft dus niet de klant zelf te zijn.

**Waarom zou je persona’s gebruiken?**

* Abstracte data roep je met een persona tot leven: ‘Zou Ilse ons programma leuk vinden?’
* Je hebt als Scrumteam een gedeeld beeld van je werkelijke doelgroep(en).
* Persona’s vergroten het inlevingsvermogen van je Scrumteam. Dit vergroot dan weer de kans dat je klantgericht te werk gaat.

**Hoe kom je tot een goed persona?**

* Start bij de collega’s die veel contacten met klanten hebben
* Ga na welke klantdata je al uit onderzoeken en databases kan halen en analyseer deze
* Definieer vervolgens de belangrijkste doelgroep(en) en maak voor elke groep een persona aan (je vindt templates op het internet die je kunnen helpen)
* Visualiseer je persona dmv een naam en een gezicht
* Vul het beeld dat je had je al had van je doelgroep voortdurend aan tijdens het project
* Print de persona’s en hang ze op in de werkruimte, gebruik ze zelfs in je presentatie

**Wat zijn user stories?**

* User stories worden gebruikt binnen agile werkomgevingen als een manier om de gewenste functies van je product te beschrijven
* Het zijn beknopt opgeschreven werkzaamheden die het scrum team moet uitvoeren
* User stories zijn de meest gebruikte manier om je product backlog met to do’s te vullen
* Een user story moet op één post-it passen
* Het is de bedoeling dat je de user stories eerst bespreekt met het team en de klant 
* Acceptatiecriteria of feedbackrondes bevestigen of de user story goed is uitgevoerd

**Voordeel user stories?**

* Vertrekken vanuit het perspectief van de klant: \n **end user first**
* Zijn begrijpelijk voor iedereen (ook niet-vakidioten)
* Als je weet waarom je stakeholder een bepaalde functionaliteit wil, kan je daar ook creatief op inspelen
* User stories promoten multidisciplinaire samenwerking, want ze zijn niet meteen opgedeeld in deeltaken voor elk teamlid

**DEEP Product Backlog**

* Detailed (gedetailleerd): een goede product backlog heeft voldoende items om enkele sprints te vullen. Items die ‘sprintklaar’ zijn, moeten gedetailleerd genoeg zijn zodat het team ze kan oppakken. 
* Estimated (ingeschat): de omvang van elk onderdeel moet goed ingeschat worden 
* Emergent: je product backlog ontwikkelt zich verder naarmate je project vordert
* Prioritised: de meest waardevolle (of risicovolle!) items staan bovenaan.

**Wat zijn story points?**

* Story points geven aan hoeveel moeite het jouw team kost om de user stories op hun backlog te realiseren
* Story points zijn geen totale, maar relatieve eenheden

**Wat zijn de voordelen van inschatten met story points?**

* Schatten in story points gaat sneller en preciezer: je gaat geen nutteloze discussies over tijd voeren
* Je kan er de relatieve grootte en complexiteit van een backlog-item ten opzichte van de andere mee weergeven zonder de exacte werktijd te kennen.
* Onafhankelijk van wie de product backlog opmaakte: ervaren vs. minder ervaren teamlid
* Ook tijd schatten we vaak relatief in: ‘Dit is klaar in minder dan een dag / hoogstens een week’
* De discussie over de relatieve waarde van elk onderdeel tussen teamleden onderling helpt je project vooruit

**De snelheid van je team =**

**het aantal gerealiseerde story points per sprint**

**Hoe werkt zo’n burndown chart?**

* In de sprint planning schat het team met story points in hoeveel moeite elk onderdeel kost
* Het totale aantal story points per project geeft weer hoeveel werk het team kan realiseren per sprint
* Op de burndown chart houdt de scrum master bij hoeveel punten er écht gerealiseerd zijn (volgens de definition of done en de acceptatiecriteria) en hoeveel er nog over zijn
* Zo kan hij/zij de snelheid (velocity) van het team meten
* Zo’n chart geeft betere inschatting of je de deadline gaat halen, want gaat uit van gerealiseerd werk

Velocity chart

vergelijkt aantal geschatte story points (to do) met aantal gerealiseerde (done)

**Wat doe je met onafgewerkte stories aan het einde van een sprint?**

* Als je sprint backlog items niet klaar zijn (done) volgens de definition of done, mogen ze niet meegerekend worden in je eindresultaat!
* Neem onafgewerkte items en story points mee naar een volgende sprint: dit heet een carry-over.

**Wat is swarming?**

* Het hele team focust samen op 1 user story naar het einde van elke sprint toe
* Doel: deze user story zo snel mogelijk af krijgen om bottlenecks of carry-overs te vermijden.

**Wat is slacking?**

* Slack is de tijd die je je als team kan permitteren zonder de oplevering van de sprint of je ganse project in gevaar te brengen
* Kleine projecten kennen vaak te weinig slack, grote vaak te veel
* Schat daarom je werkuren realistisch in
* Bereken niet de minimale tijd die vereist is om een bepaalde taak te vervullen (time on task), maar de tijd die een taak in beslag neemt inclusief onderbrekingen

time hacks

* **Get things done**
* **Eat the frog**
* **Werk of studeer met behulp van Pomodoro**
* **Doe dringende en belangrijke zaken eerst**

**Get things done**

* Verzamel al je to do’s: kort, lang, school of privé, korte én lange termijn
* Neem elke dag je to-do-lijstje en duid de drie taken aan die je vandaag zéker moet oppakken. 
* Gebruik een scrumbord om je to do’s te ordenen (to do / busy / done): zo zie je ook ‘work in progress’
* Als je het lastig vindt om te beginnen, verdeel je to do’s dan in kleinere stukken (sprints!)
* Doe alles wat je meteen kan doen en kunt afronden ook meteen 
* Zet taken die meer dan 30 minuten vragen in je agenda

\n

**Eat the frog**

* De enige time hack die succesvolle ondernemers gemeenschappelijk hebben? Ze staan vroeg op.
* Start je dag met de taak waar je het meest tegenop ziet.
* Heb je deze ‘kikker’ op? Dan zal de rest veel makkelijker gaan.

**Werk of studeer met behulp van Pomodoro**

* Het doel van deze techniek is om korte periodes van intense focus te plannen zodat je zo min mogelijk afgeleid bent tijdens het uitvoeren van je taak.
* Kies een taak uit die je volledige focus vraagt. Zet een stopwatch voor 25 minuten en laat daarna de timer gaan. De bedoeling is om in deze 25 minuten volledig gefocust te blijven werken of studeren. Neem vervolgens 5 minuten pauze.
* De taak hoeft niet per se af. Het belangrijkste is dat je vooruitgang boekt.
* Na 4 pomodoro’s neem je 25 minuten pauze. Begin dan weer van vooraf aan.

**Doe dringende en belangrijke zaken eerst**

* Houd de tijd bij die je aan elke activiteit besteedt: zodra een taak meer dan 20 min duurt, hoort ze in je agenda


* Ben je productiever in de avond? Blokkeer dan die tijd om dingen af te werken
* Zet ook pauzes in je planning
* Doe één taak per keer en timebox ze
* Geef jezelf buffer- of slacktijd en zet die ook in je agenda
* Bekijk elke dag wat je de volgende dag moet doen: daar slaap je beter van

\