Hva er en App MVP Sprint?

Hva det er

Oppdraget starter med å avklare hvilket problem produktet skal løse, hvem de primære brukerne er, og hva de først trenger å få gjort. Deretter konsentreres arbeidet om de primære brukerflytene: det lille antallet reiser som gjør produktet nyttig fra første dag. Et typisk omfang kan omfatte produktdefinisjon, nødvendige skjermbilder, avtalt appfunksjonalitet, antakelser om data og integrasjoner, kvalitetskontroller og praktisk forberedelse til lansering. Den konkrete tekniske tilnærmingen avhenger av produktet, eksisterende ressurser og den avtalte plattformen. Sprinten fokuserer på en sammenhengende første versjon bygget rundt de avtalte kjerneflytene. Den er en strukturert måte å gjøre tidlige valg synlige, testbare og leverbare på. Funksjoner som ikke støtter kjernemålet for første versjon, dokumenteres som fremtidige vurderinger i stedet for å bli lagt stille til i et fast omfang.

Hvem det er for

En App MVP Sprint passer for team som:

• Har en definert produktidé eller et forretningsproblem, men trenger hjelp til å gjøre det om til en realistisk første versjon
• Ønsker å validere en målrettet kundereise før de investerer i et bredere produktveikart
• Trenger én ansvarlig leveranseprosess for produktomfang, grensesnittbeslutninger, utvikling og forberedelse til lansering
• Skal erstatte uformelle prototyper, regneark eller manuelle steg med en første brukbar appopplevelse

Hva det hjelper med å klarlegge

En MVP-sprint bidrar til å avklare:

• Hvilket brukerproblem og hvilken primær flyt første versjon bør håndtere, og hvilke ideer som bør vente
• Hvilke antakelser, avhengigheter, innhold, integrasjoner eller godkjenninger fra kunden som må avklares før utviklingen kan gå videre
• Hvilke funksjoner som er nødvendige for en testbar versjon, og hvilke som er ønskelige forbedringer for et senere veikart
• Hvilken testing, hvilket eierskap og hvilken lanseringsforberedelse som er praktisk innenfor det avtalte omfanget og tidsplanen

Hva er inkludert

• Skriftlig bekreftelse av omfanget som beskriver målet for første versjon, plattformen, de avtalte brukerflytene og leveransegrensen
• Målrettet produkt- og grensesnittdefinisjon for de nødvendige skjermbildene og interaksjonene i omfanget
• Utvikling av de avtalte MVP-funksjonene, med antakelser og avhengigheter dokumentert etter hvert som de oppstår
• Praktisk testing av de avtalte brukerflytene før overlevering eller forberedelse til lansering
• Støtte til lanseringsberedskap tilpasset den avtalte plattformen, kontotilgangen og ansvaret for innsending
• Kildekode, dokumentasjon og et overleveringssammendrag som viser hva som ble levert, hva som trenger innspill fra eieren, og hva som hører hjemme i en senere fase

Hva er ikke inkludert

• En ubegrenset funksjonsliste, ubegrensede revisjoner eller automatisk inkludering av alle ideer som drøftes i løpet av sprinten
• Komplekse backend-plattformer, markedsplassfunksjoner, sanntidsvideo, avanserte dataprogrammer eller omfattende samsvarsarbeid, med mindre det avgrenses separat
• Et løfte om lanseringstidspunkt, godkjenning i App Store eller Google Play, brukeropptak, kommersielle resultater eller uavbrutt tredjepartstjeneste
• Løpende produktstyring, vedlikehold eller videre funksjonsutvikling etter at oppdraget er avsluttet, utover den avgrensede støtten etter lansering for leverte punkter i omfanget
• Arbeid som avhenger av innhold, kontoer, juridiske beslutninger, eksterne leverandører eller integrasjoner som ikke er tilgjengelige eller ikke er bekreftet i omfanget

Når skal den velges

Velg en App MVP Sprint når hovedutfordringen er å bestemme hva den første nyttige versjonen skal være, og deretter levere den versjonen med disiplin. Den kan passe for et team i tidlig fase, en etablert virksomhet som tester en ny tjenestemodell, eller et team som må erstatte en manuell kundeprosess med en målrettet appreise. Den er mest effektiv når det finnes en navngitt beslutningstaker, tilgang til personene som forstår brukerproblemet, og vilje til å holde versjon én bevisst smal. Den passer mindre godt når produktretningen fortsatt er svært usikker, kjerneflyten for brukerne ennå ikke kan beskrives, eller de nødvendige integrasjonene og driftsavhengighetene er ukjente. I slike tilfeller kan en discovery- eller produktplanfase være et mer nyttig utgangspunkt før man forplikter seg til utvikling.

Vår tilnærming

Vi begynner med å bekrefte ønsket resultat, de primære brukerne, plattformen og leveransegrensen skriftlig. De første samtalene handler om kjernereisen snarere enn en lang funksjonsliste: hva en bruker må kunne gjøre, hvilken informasjon som trengs, og hva som vil gjøre første versjon sammenhengende. Vi registrerer antakelser om innhold, integrasjoner, kontoer, godkjenningsansvar og eksterne avhengigheter, slik at de ikke blir skjulte leveranserisikoer senere. Under utviklingen holder vi det avtalte omfanget synlig og forklarer konsekvensene av enhver ny forespørsel før den behandles som inkludert. Testingen tar utgangspunkt i de avtalte brukerflytene og praktiske lanseringsforhold. Ved overleveringen får teamet et tydelig bilde av avgrensningen for første versjon, arbeidet som er fullført, og punktene som bør flyttes til et senere veikart eller et eget omfang.

Ofte stilte spørsmål

Beslektede artikler