I agil systemutveckling, t ex med hjälp av Kanban eller Scrum, brukar man använda en behovslista som kallas "backlog". Det är ett lite olyckligt namn eftersom det antyder att den innehåller det som ännu inte blivit gjort, sådant man ligger efter med. Men så är det inte.
Behovslistan är en sorts prioriteringslista, ett slags kö där man strängt prioriterar mellan behoven så att den dyrbara tiden alltid ägnas åt det som är mest värdefullt. Systemutvecklarlaget är en trång sektor i detta värdeflöde, så man behöver välja bort merparten av alla behov. Därför behöver dessa rangordnas.
Men backloggen är något mer än bara ett prioriteringsverktyg: backloggen är samtidigt en bild av värdeflödet inom en utvecklingsorganisation. Man kan likna den vid ett raffinaderi: i botten kommer luddiga ideer in, som sedan förfinas till tydliga funktionsbeskrivningar och bryts ner till implementerbara kravpunkter som hamnar överst. Det är ju nämligen lönlöst att prioritera upp något som inte är implementerbart.
I regelverket runt Scrum är detta görbarhetskriterium uttalat: varje utvecklarlag ska ha en tydlig Definition of Ready som bestämmer om något är implementerbart eller ej. Det betyder att den översta delen av behovslistan får en egen sektion: en lista med görbara saker. Scrum förtydligar att det är lönlöst för en produktägare (personen med den höga hatten) att komma till planeringsmötena utan görbarheter.
Denna princip om att sektionera behovslistan för att synliggöra värdeflödet kan man med fördel tillämpa på fler ställen i listan än överst. Definition of Ready visar att det finns ett sista förfiningssteg samtliga ärenden måste passera om de ska göras. Men visst måste de förfinas dessförinnan? Arbetas med? Kan man inte synliggöra även dessa förfiningssteg? Jo, och när man gör det kan man märka att arbetet med behovslistan blir lite tydligare.
Ett görbarhetskriterium för ett ärende består oftast av två delar: att frågetecknena ska vara uträtade (inga öppna frågor, all nödvändig information på plats, tydligt acceptanskriterium), samt att ärendet inte ska vara för stort. Många lag anger storleksbegränsningen till "inte större än att två personer kan färdigställa det på en vecka".
Ärenden som är för stora måste alltså brytas ner till mindre ärenden. Och detta kan bara ske efter det att alla stora frågetecken är uträtade. Alltså finns det en sektion under den översta där alla ärenden är förtydligade, men där det ännu inte är säkerställt att de går att genomföra på den önskade korta tiden. I en backlog för mjukvara är det där alla färdigspecificerade funktioner bor.
Det betyder att det under den sektionen finns en sektion för de identifierade funktioner som inte är färdigutredda än. De kanske bara har brukarberättelsens formulering "Som roll vill jag funktion för att nytta", men inte någon beskrivning av hur den ska implementeras, eller något acceptanskriterium.
På så sätt kan vi prioritera inom varje sektion, och ta de översta i varje sektion och öka värdet på dem så att de får flytta upp en våning. Detta skapar synlighet och gör behovslistan lite lättare att arbeta med.
Inga kommentarer:
Skicka en kommentar