Vad betyder affärsvärde?

Jag har följt och varit inblandad i en tråd i ett forum på Pellesoft.se som handlar om vad värde betyder i ett agilt projekt. Man pratar hela tiden om att man ska leverera affärsvärde tidigt och ofta men vad betyder värde. Den enkla definitionen av affärsvärde är enligt mig ”något som beställaren kan använda i sin verksamhet för att tjäna pengar”.

En definition av värde som Tom och Kai Gilb har är:
Value is a perceived benefit: that is, the benefit we think we will get from something. It’s is relative to a stakeholder.

Alltså värde är något som är relevant för en intressent och som den intressenten uppfattar som en fördel.

Om man sedan pratar om affärsvärde så måste man också definiera vem intressenten är och i en försäljningssituation pratar man om tre olika typer av köpare:

Ekonomisk: Den ekonomiska köpare är den som skriver under kontraktet, ser till att projektet får de ekonomiska resurser det behöver och den enda person som kan säga ja till ett projekt.

Teknisk: Den tekniska köpare är den eller de som ansvarar för att projektet eller produkten som köps in möter tekniska specifikationer och organisationens normer. Tekniska köpare kan säga nej till ett projekt eller en produkt.

Användare: Slutanvändare av en produkt eller system. Kan också säga nej.

När man har slutfört en försäljning och fått ett signerat avtal är det allt för ofta som tekniska köpare och användare tar över projektet och den ekonomiska köparens behov (eller utlovat affärsvärde), samt hur de ska levereras, förbises.

Okej, så vidare till en definition av affärsvärde:
Business Value is the perceived benefit the Economic Buyer (and ideally the organization) will get from making investments to improve something of importance to them.

Äffärsvärde är alltså, precis som värde, en uppfattad fördel som den ekonomiska köparen kommer att få ut av en investering.

Hur mäter man då affärsvärde? Affärsvärde kan vara svårt att mäta direkt men det kan mätas om man använder en teknik som kallas Measurable Objectives. Därför kan vi säga att vi levererar affärsvärde om vi är på väg att uppfylla den ekonomiska köparens mätbara mål. Dessa mätbara mål bryts sedan ner till features som implementeras i systemet och varje feature uppfyller en eller flera av de övergripande målen.

Jag var på en presentation idag av Ryan Shriver, www.theagileengineer.com, och vi gjorde ett antal övningar runt Measurable Objectives vilket var väldigt intressant. Han hade även beräkningar där man kunde avgöra hur väl olika features man planerar att implementera uppfyller målen och vilken relation det finns mellan kostnad för implementationen och levererat affärsvärde. Detta kan man sedan då använda för att avgöra om man ska implementera feature A eller B.

Agile estimering och plannering

Tidigare har jag förespråkat att använda T-shirt sizing när man estimerar produktbacklog och sedan story points till sprintbacklog-tasks men efter att ha lyssnat på Mike Cohn idag så får jag nog tänka om! Visserligen ska man inte ändra det som funkar och i de projekt jag har varit med så har det fungerat riktigt bra. Men de nackdelar med t-shirt sizing som han tar upp går ju inte att bortse ifrån.

Ett problem är att använda M, L och XXL när man estimerar features på produktbackloggen är att man inte kan addera dessa tillsammans och en kund kommer alltid att vilja veta när man ska vara klar med ett projekt. Att då svara att vi är klara om 4 small, 3 medium och 2 large funkar inte. Man måste ha estimat som går att addera så att man kan ta reda på vilken hastighet man har och därmed också kunna säga när i tiden man kommer att vara klar.

Så vad Mike föreslår är man ska använda story points när man estimerar de items man har på sin produktbacklog. Den typen av estimering gör man normalt innan första sprinten när man gör sin releaseplanering. Man bör försöka komma igenom hela produktbackloggen men inte lägga för mycket tid på varje item (ca 20 i timmen bör man klara av). Nya items kommer att komma in på produktbackloggen kontinuerligt så därför måste man också kontinuerligt estimera under varje sprint. För att estimera produktbacklogen funkar det alldels utmärkt att använda sig av Planning Poker och då behöver man heller inte konverera sina estimat till timmar.

När man sedan ska planer det jobb man ska göra i första sprinten måste man veta vilken hastighet teamet har. Om man har ett team som har genomfört ett antal sprintar är det ju inget problem men om man har ett nytt team så finns det även tekniker för att ta reda på vilken hastighet teamet kommer att ha. Hastigheten baserar man då på hur mycket teamet tror att de kommer att kunna hinna med under nästa sprint och använder det som teamets hastighet.

När teamet sedan ska bryta ner features från produktbackloggen till uppgifter i sprintbackloggen måste uppgifter mätas i ideala timmar. Vi har gjort så att vi har spelat planning poker och satt story points på uppgifterna och sedan räknat om dessa till ideala timmar. Jag frågade Mike vad han tyckte om det och han sa att det är nog i det läget bättre att göra det ”the old fashion way” och bara sätta timmar på de olika uppgifterna. Jag har alltid förespråkat att man ska, även på uppgiftsnivå, dra nytta av allas input i estimaten men Mike menar att om man har en databasexpert i temat som säger att en uppgift tar fyra timmar så är det bara att sätta fyra timmar på den uppgiften. Att implemntera en feature på produktbackloggen blir mest troligt ändå flera olika uppgifter, tex att skapa en stored procedure, att modifiera objektmodellen, att anpassa gränssnittet samt att testa de olika delarna. Och då är det bäst att de olika experterna för de olika områdena får sätta timmar på uppgifterna.

Det jag tror att jag kommer att ta med mig till mitt nästa projekt är att lära mig mer om user stories för att få en bättre produktbacklog. Estimera produktbackloggen mha planning poker i story points och sedan bryta ner den till tasks i sprintbackloggen och direkt sätta optimalatimmar på dessa.

Man blir så lycklig när man känner att bitar faller på plats! Nu måste bara se till att också uppdatera min kurs :-D

Fråga via Messenger på min blog

Det är fantastiskt kul när någon kontaktar mig på Messenger genom min blog. Då känns det verkligen att det finns någon där på andra sidan som läser det man skriver då och då. Idag hände det för andra gången men den här gången var jag på lunch och kunde inte svara :-(

Frågan handlade om hur man estimerar uppgifter i en sprintplanering i Scrum och om man bör dela upp estimaten för en uppgift i implementation respektive i test.

På Sprint Definition Meeting (som man har innan Sprint Planning Meeting) kommer teamet överens med produktägaren vilka product backlog items man ska implementera under den kommande sprinten. Dessa bryter sedan teamet ner till uppgifter under sprintplanneringen och varje uppgift estimeras. Dessa uppgifter ska estimeras utifrån ett sedan tidigare definierat klart-begrepp där det i min värld absolut ingår test!

Så säg att "Klart" för ett specifikt team betyder "Kodat, Verifierat, Granskat, Incheckat", ja då ska estimatet på 5 story points innebära att det är just kodat, verifierat, granskat och incheckat. Om klart-begreppet istället är "Kodat & Incheckat" (vilket det är för många utvecklare) så har man aktivt valt att lägga test utanför sprinten.

Det kan så klart också vara helt okej att lägga test utanför sprinten. Om man tex har en testavdelning och en testprocess som är implementerad och fungerar bra så tycker jag inte att man ska riva den och flytta in testresurserna i teamen. I alla fall inte initialt, utan då tycker jag att man ska anpassa sig till det man har och se till att man ökar kvaliteten på sina leveranser till testavdelningen tex genom testdriven utveckling.

John, hoppas att det här var svar på frågan du ställde på messenger och om inte är det bara att du hör av dig igen!