Hvad er en App MVP Sprint?

Hvad det er

Opgaven begynder med at afklare, hvilket problem produktet skal løse, hvem de primære brugere er, og hvad de først har brug for at kunne gennemføre. Derfra koncentrerer arbejdet sig om de primære brugerflows: det lille antal forløb, der gør produktet nyttigt fra første dag. Et typisk omfang kan omfatte produktdefinition, væsentlige skærmbilleder, aftalt app-funktionalitet, antagelser om data og integrationer, kvalitetskontrol og praktisk forberedelse af release. Den præcise tekniske tilgang afhænger af produktet, dets eksisterende aktiver og den aftalte platform. Sprinten fokuserer på en sammenhængende første release bygget op omkring de aftalte kerneflows. Den er en struktureret måde at gøre tidlige valg synlige, testbare og leverbare. Funktioner, der ikke understøtter kerneresultatet for den første release, dokumenteres som fremtidige overvejelser i stedet for i stilhed at blive tilføjet et fast omfang.

Hvem er det for?

En App MVP Sprint passer til teams, der:

• Har en defineret produktidé eller et forretningsproblem, men har brug for hjælp til at omsætte det til en realistisk første release
• Vil validere et fokuseret kundeforløb, før de investerer i en bredere produkt-roadmap
• Har brug for én ansvarlig leveranceproces for produktomfang, beslutninger om brugerflade, udvikling og forberedelse af release
• Vil erstatte uformelle prototyper, regneark eller manuelle trin med en første brugbar app-oplevelse

Hvad det hjælper med at afklare

En MVP-sprint hjælper med at afklare:

• Hvilket brugerproblem og hvilket primært flow den første release skal adressere, og hvilke idéer der bør vente
• Hvilke antagelser, afhængigheder, indhold, integrationer eller kundegodkendelser der skal afklares, før udviklingen kan fortsætte
• Hvilke funktioner der er væsentlige for en testbar release, og hvilke der er ønskværdige forbedringer til en senere roadmap
• Hvilken test, hvilket ejerskab og hvilken forberedelse af release der er praktisk mulig inden for det aftalte omfang og den aftalte tidsplan

Hvad er inkluderet

• Skriftlig bekræftelse af omfanget, der beskriver målet for den første release, platformen, de aftalte brugerflows og leverancens afgrænsning
• Fokuseret definition af produkt og brugerflade for de væsentlige skærmbilleder og interaktioner i omfanget
• Udviklingsarbejde for de aftalte MVP-funktioner, hvor antagelser og afhængigheder dokumenteres, efterhånden som de opstår
• Praktisk test af de aftalte brugerflows før overdragelse eller forberedelse af release
• Støtte til release-parathed, der passer til den aftalte platform, kontoadgang og ansvaret for indsendelse
• Kildekode, dokumentation og et overdragelsesresumé, der viser, hvad der blev leveret, hvad der kræver ejerens input, og hvad der hører til en fremtidig fase

Hvad er ikke inkluderet?

• En ubegrænset backlog af funktioner, ubegrænsede revisioner eller automatisk medtagelse af enhver idé, der drøftes under sprinten
• Komplekse backend-platforme, markedspladsfunktioner, realtidsvideo, avancerede dataprogrammer eller bredt compliance-arbejde, medmindre det afgrænses separat
• Et løfte om lanceringstidspunkt, godkendelse i App Store eller Google Play, brugeradoption, kommercielle resultater eller uafbrudt drift af tredjepartstjenester
• Løbende produktledelse, vedligeholdelse eller udvikling af fremtidige funktioner efter opgavens afslutning ud over den afgrænsede support efter lancering for leverede punkter i omfanget
• Arbejde, der afhænger af indhold, konti, juridiske beslutninger, eksterne leverandører eller integrationer, som ikke er tilgængelige eller ikke er bekræftet i omfanget

Hvornår du skal vælge det

Vælg en App MVP Sprint, når den centrale udfordring er at beslutte, hvad den første nyttige version skal være, og derefter levere denne version med disciplin. Den kan passe til et team i en tidlig fase, en etableret virksomhed, der afprøver en ny servicemodel, eller et team, der skal erstatte en manuel kundeproces med et fokuseret app-forløb. Den er mest effektiv, når der er en navngiven beslutningstager, adgang til de personer, der forstår brugerproblemet, og vilje til at holde version ét bevidst smal. Den er mindre egnet, når produktretningen stadig er meget usikker, kerneflowet for brugeren endnu ikke kan beskrives, eller de nødvendige integrationer og driftsmæssige afhængigheder er ukendte. I de tilfælde kan en discovery- eller produktblueprintfase være et mere nyttigt udgangspunkt, før der indgås en forpligtelse til udvikling.

Vores tilgang

Vi begynder med at bekræfte det tilsigtede resultat, de primære brugere, platformen og leverancens afgrænsning skriftligt. De første samtaler fokuserer på kerneforløbet frem for en lang liste af funktioner: hvad en bruger skal kunne gøre, hvilke oplysninger der kræves, og hvad der vil gøre den første release sammenhængende. Vi registrerer antagelser om indhold, integrationer, konti, ansvar for godkendelser og eksterne afhængigheder, så de ikke senere bliver skjulte leverancerisici. Under udviklingen holder vi det aftalte omfang synligt og forklarer konsekvensen af enhver ny anmodning, før den betragtes som omfattet. Testen tager udgangspunkt i de aftalte brugerflows og praktiske release-betingelser. Ved overdragelsen får teamet et klart billede af afgrænsningen af den første release, det udførte arbejde og de punkter, der bør flyttes til en senere roadmap eller et separat omfang.

Ofte stillede spørgsmål

Relaterede artikler