De usynlige kvalitetskrav

Hvilken interessent har nogensinde bedt om en løsning, der kan skalere til tre gange den normale belastning? Hvilken bruger efterspørger tidligt en svartid på under 2 sekunder? Det sker sjældent. Lige så sjældent som pålidelighed, sikkerhed eller evnen til at vedligeholde løsningen diskuteres på refinement-mødet. Kvalitetskrav prioriteres oftest ikke. Lige indtil systemet er nede, siden hakker, eller kundedata ligger frit på nettet.

Velkommen til kvalitetskravene! Kravene til hvor godt systemet skal virke, ikke bare hvad det skal kunne. De gemmer sig i ni kategorier og har særligt én ting til fælles. De står sjældent i backloggen, men de har en afgørende indflydelse på, om produktet lykkes.

Efter én dag har I et fælles sprog for kvalitetskrav, en metode til at prioritere dem, og de første krav skrevet, så jeres team faktisk kan forhandle ud fra dem.

Workshoppen er case-drevet hele dagen. I arbejder på jeres eget produkt i alle øvelser og bygger videre modul for modul. Først identificerer I kvalitetskravene. Så prioriterer I dem. Derefter formulerer I de spørgsmål, der afdækker dem. Til sidst skriver I kravene.

Undervejs rammesætter korte faglige input hvert skridt. ISO 25010 som fælles sprog, en risikobaserede tilgang til prioritering, og Kano analyse til at forstå, hvorfor kvalitetskrav sjældent bliver efterspurgt. Inputtene er korte. Arbejdet er jeres.

Undervejs stiller vi de ubekvemme spørgsmål: Hjælper vores agile metoder os overhovedet med at fange kvalitetskravene? Hvorfor står der "systemet skal være brugervenligt" i kravene, og hvad skulle der have stået i stedet? Og tør du prioritere kvalitet ned, når du ved, hvad høj kvalitet koster?

På et kort formøde aftaler vi, hvilket produkt eller hvilken del af jeres system vi arbejder med som case på dagen. Deltagerne skal kunne genkende det og have en interesse i kravene.