Inledningsvis gav jag en kort introduktion till PO-rollen och beskrev vad som normalt ingår i arbetsuppgifterna och inom vilka ansvarsområden. Sedan kom jag in på hur du kan hantera användarbehov och krav. I denna post tänkte jag komma in på hur du kan hantera produktbackloggen på ett effektivt sätt.
Förstå dina kunders behov
Som jag nämnt tidigare är av de mest fundamentala byggstenarna kundernas behov och att du verkligen förstår dem. För en utförlig diskussion kring detta rekommenderar jag att du tar dig en titt på min första post i serien kring hur du bygger upp det optimala IT-utvecklingsteamet.
Jag tänkte inte repetera allt jag har sagt tidigare kring detta, men det finns några viktiga saker som är värda att trycka lite extra på. I artikeln beskriver jag hur du bär dig åt för att samla in alla behov och krav, men en annan aspekt är hur du ska tolka och förstå dessa behov, vilket inte alltid är helt enkelt.
Tänk på att användare och andra intressenter ofta har ett helt annat perspektiv när de uttrycker ett behov och det kan ibland vara svårt att översätta detta till mål, termer, behov som kan realiseras av ditt utvecklingsteam. Det jag har sett är också att vissa har en tendens att snöa in på IT-system i alla möjliga sammanhang, men i många fall är det inte alls säkert att det är IT-stöd som ska skapas.
Ett exempel på detta var när jag och en kollega var ute på ett uppdrag där personalen klagade på att de fick för lite framförhållning när större sällskap anlände. Många såg direkt möjligheten att skapa en frontend till ett bokningssystem där alla enkelt kunde gå in och se vilka besökare som var inplanerade. Ett problem var dock att inte alla anställda hade tillgång till en dator och det andra problemet var att några hade väldigt liten datorvana.
Så det vi kom fram till var att just det specifika problemet löstes bäst med en traditionell anslagstavla för att lösa det akuta behovet. Senare ersattes den med en elektronisk anslagstavla som var direkt kopplad till bokningssystemet, men det akuta behovet löstes genom att införskaffa en manuell anslagstavla för 100 kronor som installerades på mindre än fem minuter!
Ett annat problem vid behovsinsamlingen är att de kan vara alltför vaga eller diffusa. Sådana behov kan vara ganska svåra att realisera och måste konkretiseras innan de blir användbara i praktiken. Ibland smyger sig sådana behov in i produktbackloggen och då kan det snabbt bli betydligt krångligare att hantera backloggen än du kanske hade tänkt.
Personas och user stories
I mitt tidigare inlägg i den här serien skrev jag lite om hur du kan använda dig av personas och user stories för att bättre visualisera användarbehov och olika scenarion. Detta gäller i högsta grad också för backloggen både när du ska formulera saker där och i samband med den återkommande genomgången.
Om du läser igenom de saker ni har lagt in i backloggen och reagerar på att något låter lite konstigt, inte är tillräckligt konkret eller något annat som du stör dig på. Testa då att använda dig av personas och/eller user stories och ge substans till den som ligger bakom önskemålet och försök att på så sätt sätta dig in i behovet och därmed också formulera om storyn så att den blir tydligare.
När du lyckas få produktbackloggen tydligare blir det också enklare att snabbt ta fram prototyper eller wireframes så att du kan förankra dina leveranser och låta användare och andra intressenter testa och interagera med nya versioner av produkten eller nyutvecklad funktionalitet. På det viset kan du samla in värdefull feedback och ta fram eventuella förbättringsområden.
Testresultaten kan också användas för att modifiera och förtydliga de saker du har i backloggen. Se till att hela tiden anpassa dessa saker efter användarnas behov och förväntningar. Jag har full förståelse för att det kan vara svårt att få en bra överblick över backloggen om det finns hundratals saker där, men försök att strukturera upp dem någorlunda så att inte alla är i status ”att göra”.
Några saker kanske bara är på idé-stadiet och inte realiserbara på flera år och då kommer den bara ligga och störa i backloggen. Försök att lyfta ut alla saker som ligger på lite längre sikt i en egen kategori så att du enkelt kan filtrera fram de saker som faktiskt är aktuella i den vyn du tar fram.
Prioritera saker i produktbackloggen
En annan viktig sak som jag också nämnde i mitt första inlägg i den här serien handlar om att prioritera saker i backloggen. Det är du som PO som har huvudansvaret för att prioritera upp och ner saker i backloggen. Ingen annan än du har rätt att prioritera om saker där.
Det är viktigt att detta är väldigt tydligt för alla. Du kommer hamna i situationer när andra vill förändra prioriteringsordningen i backloggen och enda sättet att göra detta är att försöka påverka dig som PO att göra det.
Jag nämnde olika metoder för att underlätta prioriteringen, men gav kanske inte in så många konkreta exempel på hur du kan använda dessa metoder. Jag tänkte ge ett mer praktiskt exempel på användning av MoSCoW-metoden.
Anta att du är PO för ett företag som har hand om e-handelsplattform som består av många olika delar. Inom dessa olika delar finns det åtskilliga saker som behöver utvecklas och därmed också prioriteras i backloggen.
”Must-haves” är funktioner eller egenskaper som är absolut nödvändiga för att produkten ska fungera och uppfylla de mest basala användarbehoven. Det kan röra sig om funktioner som t.ex. inloggningsfunktionen, artikelregistret, kundvagnen, betalningsfunktionen med flera. Alla dessa saker är vitala delar av applikationen och utan någon av dessa blir applikationen obrukbar.
”Should-haves” är saker som är viktiga för att förbättra användarupplevelsen och möta användarnas förväntningar, men kanske inte lika kritiska som alla saker i föregående kategori. Här finns saker som till exempel möjligheten att söka ut produkter, filtrera produktlistor, välja transportsätt, välja betalningssätt, byta användargränssnitt med mera. Dessa saker bör finnas med men det finns utrymme för justeringar och omprioriteringar baserat på ändrade förutsättningar.
”Could-haves” är funktioner som är önskvärda och kan ge mervärde till produkten och för användarna, men de kan också skjutas upp eller tas bort utan att kritiska funktioner påverkas. Här kan det hamna saker som t.ex. produktrecensioner, personliga användaranpassade rekommendationer baserade på tidigare köpbeteenden, delning via sociala medier, SEO-optimering med mera. Dessa saker kan vi ta med om det uppstår utrymme, men annars inte.
”Wont-haves” är den sista kategorin och här hittar vi funktioner som medvetet har prioriterats bort av någon anledning. Sådana funktioner kan vara att möjliggöra betalning med andra valutor, integrera applikationen med olika affärssystem eller BI-system med flera. Tänk också på att noggrant dokumentera varför saker hamnar i den här kategorin eftersom någon kan ifrågasätta varför en viss funktion har hamnat här.
Sist men absolut inte minst vill jag också poängtera vikten av att involvera användarna i prioriteringsprocessen. Det är viktigt att de känner sig delaktiga i ett tidigt stadium eftersom detta också bidrar till att bygga upp förtroendet mellan teamet och användarna/beställarna.
Jag har ju varit inne lite på det här förut, men i nästa artikel tänkte jag gå igenom hur du som PO kan kommunicera och samarbeta med alla intressenter.
