Låt oss ta ett djupdyk i Agile Inception och HUR DU ANVÄNDER LOOP-ANSATSEN! Men först, detta är den första artikeln av tre som förklarar Agile Inception – Loop-ansatsen. Samtliga artiklar är tagna ur Softhouse utgåva Agile inception in 60 min. Vi hoppas att du uppskattar läsningen och hur man kan kombinerar olika agila inceptionstekniker. Kom ihåg att loop-ansatsen av de tre huvudsakliga agila inceptionstrategierna vi använder oss av inom denna artikelserie är tre av många som finns där ute. Givetvis väljer du själv inceptionstrategierna som passar dig för att sätta samman den loop du behöver. Njut av läsningen och lycka till med dina loopar!

Genom att använda en kombination av tekniker som utförs genom en serie workshops kan vi engagera olika grupper av människor i organisationen beroende på vilken typ av förändring vi är involverade i. Varje loop har ett specifikt omfång för att skapa affärsnivåresultat. Som agila inceptionstrategier fungerar looparna för enskilda agila team och skalade miljöer där flera team samarbetar om att utveckla produkter och tjänster.

Men som alltid måste du göra ditt hemarbete och anpassa idéerna i denna publikation till din organisation och dina behov. Denna artikel presenterar inte några mirakellösningar, utan vi hoppas att den snarare agerar som en inspirationskälla och hjälp för att accelerera affärsresultatet genom ett agil utförande, ”att göra rätt sak rätt och snabbt”. Vi hoppas också att artiklen hjälper dig att sätta samman den loop du behöver för ditt nuvarande arbete. Se detta är en kontinuerlig process av lärande och förbättring!.

LOOP 1: KLAR, FÄRDIG, GÅ!

För en organisation som levererar komplexa tjänster genom flera olika kanaler i en kundlivscykel, som har ett behov av avgörande affärsresultat för att underlätta ett Go/No Go-beslut innan man går vidare med releaseplanering och “projekt chartering”, är ”Klar, Färdig, Gå” en agil samarbets-loop som levererar en affärsmodell och en storymap, till skillnad från en traditionell process. ”Klara, färdiga, gå”-loopen levererar på ca 5-10 arbetsdagar och denna loop använder samarbetsbaserade agila tekniker för att generera ett liknande resultat som en traditionell genomförbarhetsstudie. En förutsättning för att lyckas med loopen är att utföra teknikerna med ett samlokaliserat, tvärfunktionellt team och att ha viktiga intressenter tillgängliga parallellt för snabba svar och validering av resultat.

När man ska använda Loop 1?

Loop 1 används när svaret är ja på någon av följande frågor:

• Är din produkts kontext en komplex tjänst med många funktioner som levereras genom flera kanaler i en kundlivscykel?
• Behöver du fånga avgörande affärsdata i förväg för att underlätta ett Go/No Go-beslut innan du går in i release-planeringen?
• Har du beslutsfattande intressenter som begär förstudier och tyngre kravspecifikationer i förväg för att godkänna ansträngningen, då kan denna loop passa dina behov.

Tidsram

5-10 arbetsdagar.

Låt oss gå in i loopen

Det är mänskligt att försöka förstå och vilja få reda på varför “vi går åt just det här hållet”? Varför gör vi denna produkt eller varför genomför vi detta projekt? Dessa frågor behöver ett inspirerande och kommunikativt svar för att få validering och bli godkänt.

IMPACT MAPPING

Mind mapping är en lämplig teknik för att öka kreativiteten och hjälpa dig att ta reda på – och också att komma ihåg ”varför” – genom en sammanlänkad visualisering. En bra praxis är att bygga mind maps och impact maps med klistermärken på en whiteboard. Detta format gör att alla i ett team kan delta och det är lätt att göra ändringar.

Impact mapping skapades av Gojko Adzic som ett sätt att skifta samtalet från vad som behövs till varför vi vill uppnå en viss typ av affärsmål eller effekt och identifiera den påverkan som krävs för att nå målet. Modellen handlar om att förstå beteenden som behöver förändras bland nyckelintressenter för att uppnå ett hållbart resultat.

En impact map är ett specifikt mind map-format som organiserar dina idéer i en logisk struktur – genom att härleda den minimala mängden funktioner (vad) som behövs tillsammans med strategier för att underlätta förändrat beteende (hur) hos nyckelintressenter (vem) som behöver påverkas för att uppnå målet (varför).

• Först identifiera målet, varför är detta viktigt?
• Nästa steg, vilka intressenter/aktörer behöver vi påverka (vilka kan blockera det eller stödja målet)?
• Vilka är de faktiska områdena vi behöver att våra stake holders engagerar sig i som en önskad beteendeförändring för att vi ska nå målet?
• Slutligen, vilka organisatoriska aktiviteter och/eller mjukvarufunktioner kommer att underlätta att uppnå de önskade effekterna vi söker?
• Vid detta tillfälle kan du fokusera på att hitta den kortaste vägen genom kartan för att genomföra målet. Genom att tillämpa denna strategi får du den minst ”slösaktiga” första bilden av det arbete som krävs!

Impact mapping kan verka enkelt men ofta behövs en erfaren facilitator för att göra det riktigt bra. 

Impact mapping är ett bra sätt att inleda loop-arbetet med eftersom det är ett snabbt och strukturerat sätt att identifiera spelplanen, värde-strategin, som vi behöver komma överens om innan vi börjar arbeta mer produkt- och kapabilitetscentrerat. Men låt oss inte glömma att redan vid detta skede kommer du att ha fokuserat på de övergripande kapabilitetsområdena som kommer att driva din effekt, vi lägger bara ännu inte tid på att bryta ned kapabiliteterna till en mer uppskattningsbar nivå i detta skede.

PRODUKTVISION

Det är nu dags att övergå från Varför till Vad och bli mer produkt- och kapabilitetscentrerade. Impact mapping ger en övergripande bild av de rätta kapabiliteter som behövs för att säkerställa påverkan och nå det avsedda målet, dvs. värde-strategin. Detta mål och dess relaterade kapabiliteter kan behöva ytterligare utformning för att beskriva en produkts önskade slutstatus eller så kan det behöva valideras från ett annat perspektiv med ytterligare intressenter.

Produktvisionen är en del av planerings- och samarbetspraxisen i XP, eXtreme Programming, för att initiera identifieringen av produktansträngningen. Typiskt för XP är den lekfulla, samarbetsinriktade och accelererade naturen hos visionaktiviteterna.

Cover story

Föreställ dig din produkt som en ”cover story” för en publicerad tidning. Hur skulle det se ut?

Typiskt för dessa visions-aktiviteter är att tidsboxa dem till en halvdag för att bygga det faktiska fysiska slutresultatet. Det är också vanligt att uppmuntra till att bygga flera resultat och under sessionen begränsa till ett slutresultat (produktbox eller cover story) efter en strukturerad diskussion i teamet. Ibland används tekniker som poäng-röstning och handuppräckning för att främja deltagande, öka bidragsfaktorn och uppnå konsensus i gruppen.

Elevator Pitch

Föreställ dig en tidslucka på 30 sekunder för att sälja och/eller informera någon om din produkt. Vilken information är väsentlig för att leverera ett tydligt budskap? Elevator Pitch är ett bra sätt att sammanfatta Impact- och Vision-arbetet till en tydlig sammanfattning av produktansträngningen som du planerar att inleda.

Elevator Pitch kan dra nytta av att produceras på ett liknande sätt som visions-aktiviteterna, det vill säga att varje person bygger sin egen utkastversion och teamet samarbetar för att begränsa alternativen och diskutera sina olika tolkningar och slutligen enas om vad produktansträngningen kommer att erbjuda och för vem.

Vid detta tillfälle vet vi varför vi behöver göra vad på en övergripande nivå. Innan vi dyker djupare in i produktskapabiliteterna i mer detalj fokuserar vi på målgruppen och deras behov genom att skapa användar personas, vilket underlättar en stark kund- och användarupplevelse.

Personas 

Använd kraften hos en personas för att förstå dina kundsegment och etablera en stark designmålgrupp. En personas är en arketypisk beskrivning av en fiktiv persons egenskaper, demografi och mål som stöder planeringen av produktkapabiliteter och underlättar beslut med användarpersonas som agerar som rösten för kunden. Det är bra att producera 2-4 personas för att fånga de viktigaste kundegenskaperna bland målgruppen som kommer att illustrera de olika avvägningar som behövs göras när det gäller UX-beslut samt beslut angående globala villkor och begränsningar för den produktansträngning vi planerar att initiera.

Personas kan innehålla långa beskrivningar, vid detta skede använder vi en första initial skiss av användarpersonas som kan slutföras efter att Loop 1 har avslutats.

Var uppmärksam på – att blanda inte ihop användarpersonas med mindre informativa beskrivningar av aktörer, vilket representerar en specifik användarroll för en produkt, som t.ex. online kund.

Vid detta tillfälle har vi avslutat en snabb, liten och avskalad resa och har uppnått en överenskommelse på övergripande nivå om varför (målet och den nödvändiga påverkan) vi planerar att göra vad (produktvisionen med nyckelkapabiliteter) för vem (målgrupp/aktörer och personas).

Nu är det dags att ta ”vad” och dyka djupare in i vilka kapabiliteter som behövs för att uppfylla produktvisionen. Vi måste se till att vi har ”omfattning-före-djup” när det gäller vilken del av produkten och de produktdelar som påverkas innan vi börjar skriva våra användarberättelser.

 Customer life cycle “CLC” 

När vi letar efter produktkapabiliteter under inledningsarbetet rekommenderar vi att använda en modell för kundlivscykel för att identifiera de övergripande kundinteraktionerna som produkterfarenheten behöver omfatta. Kundlivscykeln är en modell från Customer Relationship Management (CRM)-området. Sterne och Cutlers ursprungliga modell bygger på fem grundläggande steg: nå, förvärv, konvertering, behållning och lojalitet. Vi brukar använda denna modell för att gå från produktvision och viktiga produktattribut till faktiska övergripande kapabiliteter. Vår hybridmodell nedan är mer relaterad till affärsbehov och vi har använt den i olika kundprojekt, främst inom IT- och telekomområdet.

Det är en bra modell för att förstå den nuvarande statusen för produkten (om du har en) och visualisera var våra övergripande påverkningskapsabiliteter kommer att dyka upp i den övergripande kundupplevelsen. En kund-livscykelmodell underlättar också värde prioritering när man måste fatta avvägningsbeslut mellan att lägga till nya produktkapabiliteter eller att lägga till kapabiliteter i processerna/systemen som möjliggör kundupplevelsen, ett beslut som är relaterat till var din produkt befinner sig i sin produktlivscykel.

Använd mind-mapping och klistermärken som sätt att modellera kapabiliteterna och var de behöver visas i CLC-modellen. I vissa team använder vi färgkodade klistermärken för att visualisera och separera befintliga kapabiliteter och önskade nya kapabiliteter.

På en övergripande nivå har vi nu utvidgat vårt ”vad” för att potentiellt täcka mer än bara produktkapabiliteter. Vi fokuserar fortfarande på bredd före djup, vilket innebär horisontell täckning istället för vertikal detaljnivå. Låt oss titta närmare på några nära relaterade tekniker som hjälper oss att utforska ”vad” och minimera risken för utlämnande av misstag.

CLC och kanaler

Kundlivscykler kan vara, och är ofta, ytterligare uppdelade i (kommunikations) kanaler, t.ex. butiker, webbutik osv. Beroende på var din produkt befinner sig i sin livscykel kan det vara så att fokus för din kommande produktansträngning i hög grad handlar om kundlivscykeln snarare än bara produkten. Det är viktigt att ha ett kundcentrerat perspektiv eftersom kunden inte skiljer på de faktiska produktkapabiliteterna och de stödjande processerna.

Kundresa

En kundlivscykel beskriver övergripande kundinteraktioner, medan en kundresa skildrar hela kundupplevelsen genom att visualisera varje kontaktpunkt med en produkt (eller tjänst). Använd kundresa för att identifiera kapaciteter (och villkor och begränsningar) vid varje kontaktpunkt. Om kundlivscykeln har delats upp i kanaler krävs en kundresa per kanal (eller färgkodade klistermärken).

Kontaktpunkterna är de konkreta element som utgör den totala upplevelsen av att använda en produkt (eller tjänst). Kontaktpunkter kan ta många former, från reklam till personliga kort, webb-, mobil- och datorgränssnitt, fakturor, butiker, call center och kundrepresentanter.

En kundresa är i grunden ett mycket övergripande flödesschema som visar kundens huvudsakliga steg och hur det kopplas samman med manuellt och/eller digitalt processtöd vid varje huvudsteg (dvs vilka enheter som är involverade). Återigen, sammanhanget är avgörande.

Vid detta tillfälle kan vi ha spenderat totalt 3-4 dagar på att producera avgörande resultat. Vi kan ha en preliminär lista på 30 och inte mer än 50 övergripande produktattribut, främst kapabiliteter (dvs. funktioner) men också villkor och begränsningar (icke-funktionella aspekter som behövs), kanske skrivna i formatet för användarberättelser. Vi är fortfarande i ”vad”-läge, men nu är det dags att djupdyka och bryta ned delar av våra större produktattribut som vi vet kan vara avgörande i de tidigare stadierna av den kommande produktansträngningen vi planerar att genomföra.

User case diagrams

User case diagrams har funnits ett tag, det är en av flera (många) modelleringstekniker inom UML, men vi använder dem inte för att modellera lösningen, vi använder dem för att snabbt skissa på kapabiliteten som vi behöver bryta ned. Vi håller med Alistair Cockburn om värdet av att fortfarande använda användningsfall (se hans blogginlägg från 2008 http://alistair.cockburn.us/Why+I+still+use+use+cases). Vi är målinriktade, vi är användarinriktade och vi får sammanhang som hjälper oss att förstå hur en enda mindre kapabilitet (dvs. funktion som möjligen är skriven i formatet för användarberättelser) kan existera tillsammans med andra kapabiliteter för att uppnå ett mål. Vad finns det inte att gilla med det?

Vad är då user case diagrams(på engelska use case diagrams)? Användningsfallsdiagram ger en förenklad och grafisk representation av en aktörs interaktion med en produkt, dvs. vad produkten faktiskt måste göra. Om produktvisionen representerar det övergripande målet för en produkt representerar varje kapabilitet i diagrammet en aktörs mål.

Notera att jämfört med en kundlivscykel/-resa, som beskriver den totala kundupplevelsen, fokuserar ett användningsfallsdiagram på produktkapabiliteter (funktioner) och aktörer, och det beskriver en del av kundlivscykeln/-resan. En kundresa kan ses som en uppsättning sammanfogade användningsfallsdiagram, ett per fas i kundlivscykeln. Huvudskillnaden är deras informationsperspektiv, där en kundresa visar informationsobjekten (kontaktpunkter), medan ett användningsfallsdiagram visar kapabiliteter (funktioner) och aktörer.

Identifiera aktörer, system och tjänster (= subjekt)

Baserat på produktvisionen identifierar vi aktörer genom att ställa följande tre frågor:

• Vilka aktörer finns med i en sådan produkt?
• Vilka aktörer skulle kunna vara med?
• Vilka andra system, tjänster (eller aktörer) behöver vi kommunicera med?

Kom ihåg att du redan har mycket data som producerats i din Impact Map, dina användarpersonas och din kundlivscykel!

Identifiera mål (= verb och objekt) per aktör

Baserat på de identifierade aktörerna fångar vi deras individuella mål genom att ställa frågor i följande stil:

• Varför använder en ”online kund” produkten?
• Varför skulle ”betalningshanterings-systemet” ha ett gränssnitt med oss?
• Skriv målen som verb och objekt, till exempel. Visa produkter.

Notera att denna modelleringsteknik fokuserar på att identifiera målen, det vill säga de kapabiliteter som behövs för att aktören/rollen ska kunna uppnå sina mål. Den modellerar inte behovet av icke-funktionella attribut som villkor och begränsningar. Du måste lägga till dem i din växande lista över produktattribut som behövs för att underlätta den påverkan som krävs för att göra din produktvision levande. Återigen bör du kunna spåra många av dina faktiska mål (användningsfall) till din Impact Map och kundlivscykel.

User Story Decomposition (Användarberättelser nedbrytning)

Dessa initiala kapabiliteter (skrivna som användarberättelser, dvs. epiker vid detta stadium) är för stora för att kunna implementeras. De måste brytas ned i flera delberättelser, dvs. ytterligare användarberättelser med mer detaljer. Nedbrytningen fortsätter tills användarberättelserna är tillräckligt detaljerade för implementering. Alla berättelser måste också ha en uppskattning, helst med hjälp av relativa uppskattningstekniker som ideal ingenjörstid eller story points.

Notera att nedbrytningen av berättelser är en pågående aktivitet inom agil produktutveckling. En tumregel är att ligga ett steg före i nedbrytningen jämfört med genomföringsiterationen. Just nu skapar vi output som behövs för en kommande releaseplan. När releasen har startat tillämpar vi principen om ”rullande våg” med ett steg framåt (så kallad förfining av produkt-backlog eller ”trimmning av backlog”).

Anledningen till att vi har användningsfallsdiagram är att denna loop är utformad för team och organisationer som behöver göra lite mer förhandsdetaljering som en del av planeringen av produkt-ansträngningen, dvs. releasen/releaserna. Användningsfallsdiagram-modellering är en snabb, visuell och sammanhangsstödjande teknik. När vi arbetar med nedbrytningen hjälper det utvecklingen att kognitivt zooma in och zooma ut när antalet användarberättelser börjar öka.

Nu har vi en större uppsättning kapabiliteter som vi kan spåra direkt till de övergripande kapabiliteter som behövs för att stödja den påverkan vi försöker uppnå. Vid detta tillfälle kan vi börja skapa underlaget för den affärskontext som den kommande produktansträngningen kommer att betjäna, och vi kan göra detta eftersom vi har en mycket bra översikt över de nedbrutna användarbehoven och hur de samarbetar ur aktörernas och användarnas perspektiv.

Business Model Canvas (BMC)

En business model canvas undersöker livskraften hos en produktidé, vanligtvis genom att prova röktester på prototyper, t.ex. landningssidor gentemot identifierade kundsegment. Huvudsyftet är att skapa en giltig affärsmodell eller att avsluta tidigt.

En persona tydliggör ditt kundsegment. En produktvision skärper ditt värdeförslag. En kundlivscykel/-resa hjälper dig att förstå kundrelationer, kanaler, nödvändiga nyckelresurser och potentiella partners. Ett användningsfallsdiagram identifierar övergripande produktkapabiliteter (funktioner) och vid behov hur de kan brytas ned i mindre delar. Så vid detta tillfälle har du många av de viktigaste attributen för BMC och kan fokusera på en samarbetsinriktad dialog, måla affärscanvasen tillsammans och fylla i luckorna.

Om det är ett produktarbete från grunden rekommenderar vi att du och ditt team bygger en BMC. Och även om du arbetar med att planera nästa större steg i din produkts livscykel kan det vara fördelaktigt att prova denna teknik för att verkligen fokusera på de mest kritiska stegen som krävs för att uppnå ett konkret affärsresultat.

De tekniker som hittills har presenterats i denna loop har genererat avgörande output som BMC använder som inmatning för att integrera och konstruera en inledande BMC. Efter att ha fyllt i denna information är det dags att börja tänka på kostnadsstrukturen och intäktsströmmarna. Sedan designa en hypotes och formulera en mätbar metrik. Slutligen skapa en prototyp och generera insikter från ditt kundsegment. Vi ser BMC som den främsta tekniken för att göra din Impact Map levande. De andra teknikerna som hittills har presenterats i denna loop fungerar som stödjande tekniker, främst eftersom många organisationer kan behöva en mer detaljerad förståelse av de kapabiliteter som behövs för att kunna skapa en BMC och enas om den.

Nu när vi har integrerat vår affärsoutput och vår nedbrutna, ganska stora uppsättning produktkapabiliteter (användarberättelser) i en BMC kan vi börja tänka på en mycket övergripande byggnadsordning baserad på vår värdestrategi, Produktrutkartan.

Product Roadmap (Produktrutkarta)

En produkt-ruttkarta anger planerade stora releaser, vanligtvis ett år framåt, deras mål, nyckelfunktioner och mätvärden. Kartans mål är hypoteser. Det arbete vi har gjort och den affärsoutput vi har skapat hittills bör innebära att vi kan göra kvalitativa antaganden och inte vilda gissningar om de planerade produktansträngningarna framöver.

• Version 1 fokuserar på användaranskaffning (Minimum Viable Product)
• Version 2 på aktivering och intäktsgenerering (Minimum Marketable Product)
• Version 3 handlar om att behålla befintliga användare (Minimum Marketable Feature)
• Version 4 riktar sig till en ny segment och försöker locka nya användare

En produktrutt-karta kopplar samman affärsmodellen med vår utökade lista över produktkapabiliteter, villkor och begränsningar (eventuellt befintliga i en produktbacklog som en sorterad lista över produktbacklogposter, PBIs) och länkar marknadsinsikter med produktrelease/releaser.

RELEASEPLANEN

Nu har vi, i utvecklingsteamet, allt vi behöver för att samarbeta och skapa vår Releaseplan. Detta är det sista steget i loopen och nu tittar vi på och ger initiala tids- och kostnadsuppskattningar för de kommande produktansträngningarna som planeras (dvs. releasen/releaserna). Vi rekommenderar användarberättelse-kartläggning som ett bra sätt att visualisera det arbete som krävs samt identifiera din releasestrategi.

User Story Mapping (Användarberättelse-kartläggning) 

Ordna dina kapabiliteter, dvs. dina epics och nedbrutna användarberättelser, i en strukturerad modell för att visualisera produktbacklogen som totalanvändningen av din produkt, inklusive varje aktörs användningsperspektiv. En användarberättelse-karta (tillsammans med produktvisionen) berättar hela historien om en produkt (eller tjänst).

Epics ordnas från vänster till höger i tidssekvensordning. Varje epic bryts ned i flera mindre användarberättelser. En hög position indikerar att de är absolut nödvändiga, lägre position indikerar att de är av mindre affärsmässig betydelse.

Releasplanering

Användarberättelserna som placeras högt på berättelsekartan beskriver den minsta produkten (eller tjänsten) som skulle ge funktionalitet från ände till ände och leverera affärsvärdet som utlovats av ett releasmål. Denna funktionalitet bör släppas först, innan något annat arbetas på. Rita en linje över användarberättelse-kartan för att visualisera användarberättelserna för produktversion 1.

En releaseplan specificerar kapabiliteterna, dvs. användarberättelserna, för varje produktversion och datum för release. Den är mer detaljerad än en produkt-ruttkarta, men ändå bara en tidsbaserad ryggrad för din användarberättelse-karta. Denna ”tidsplan” lämpar sig för att kartlägga långsiktiga händelser som inköp av utrustning och externa leveranser i projektet parallellt med de planerade iterationerna i releasen/releaserna. Det är också en användbar visuell hjälp för att kommunicera med affärsintressenter som är vana vid den mer Gantt-liknande synen på projekt.

Observera att vi inte främjar en stor plan i förväg med en fullständig nedbrytning i förväg av alla produktkapabiliteter/användarberättelser. En releaseplan har mer detaljerade iterationskandidater för den första iterationen, resten av releasekandidaterna hålls på en högre detaljnivå och vi använder rullande vågplanering medan vi arbetar med en iteration för att förbereda och bryta ned kommande iterationskandidater under releasen när arbetet fortskrider.

Dela den initiala produktversionen i iterationer och beräkna varaktighet

En förutsättning för releasplaneringen är den förväntade hastighet med vilken användarberättelser implementeras och iterationens längd. Det är också vanligt att ställa in en iterationskostnad (baserad på antalet personer i teamet och deras allokering).

• Hastighet = story points/iteration (25).
• Iterationslängd (4 veckor).
• Iterationskostnad (10 000 $).

Sammanfatta det totala antalet story points för releasen av produktversion 1 (75) och dela upp det i iterationer baserat på hastigheten (75/25 = 3).

• Release av produktversion 1 kommer att levereras i 3 iterationer.
• Release av produktversion 1 kommer att kosta 30 000 $.

Beräkna varaktigheten genom att multiplicera antalet iterationer med iterationslängden (3×4 = 12 veckor).

• Release av produktversion 1 kommer att levereras på 12 veckor.

Återbesök användarberättelsemodellen efter varje iteration

Eftersom ansträngningen för användarberättelser (story points) uppskattas och hastigheten (story points/iteration) ”gissas” kommer de inledande releasplanerna att återbesökas och justeras i enlighet med den verkliga uppmätta hastigheten när iterationsgenomförandet börjar.

Användarberättelsekartan kan användas som den är, men den delas vanligtvis upp i produktbacklog, releaseplan och iterationsplan av praktiska skäl, t.ex. versionskontroll, informationsdelning och lagring.

Grattis, du har avslutat loop 1!

Nu har du en Releaseplan som bygger på en Product Roadmap och är kopplad till en Business Model Canvas, som kan spåras tillbaka till din Impact Map och Product Vision. Under denna resa har du fördjupat dig i målgruppen och deras behov genom att skapa Personas och den stora mängd Capabilities som kommer att möjliggöra deras mål – och därmed dina påverkans- och affärsmål.

Copyright

Upphovsrätt: Om du önskar använda innehåll eller använda bilder som är en del av denna bok, vänligen ange källan vid användning. Upphovsrätt Softhouse Nordic AB. Vi är inspirerade av öppna källkods-communityn där principerna om öppen och fri tillgång till kunskap och resultat är centrala, och information samt erfarenheter behöver delas. Den agila gemenskapen drivs i hög grad av att bidra till och dela kunskap, och vi har mycket att tacka andra för deras arbete. Det är dags för oss att också bidra.

När vi talar om och konceptualiserar ”…. på 60 minuter” och den relaterade bloggideen ”2 cents on Agile” använde vi specifikt ”Scrum and XP from the trenches” av Henrik Kniberg som ett exempel på den typ av praktisk publikation vi ville skapa, även om du kommer att se hur ”…. på 60 minuter” skiljer sig på grund av innehållets natur och de områden vi behandlar.

Andra delen i serien publiceras nästa vecka!