Vad är en App MVP Sprint?

Vad det är

Uppdraget börjar med att klargöra vilket problem produkten ska lösa, vilka de primära användarna är och vad de behöver kunna göra först. Därefter koncentreras arbetet på de primära användarflödena: det fåtal resor som gör produkten användbar från dag ett. En typisk omfattning kan innefatta produktdefinition, nödvändiga skärmar, överenskommen appfunktionalitet, antaganden om data och integrationer, kvalitetskontroller och praktiska releaseförberedelser. Den exakta tekniska lösningen beror på produkten, befintliga tillgångar och den överenskomna plattformen. Sprinten fokuserar på en sammanhängande första release byggd kring de överenskomna kärnflödena. Den är ett strukturerat sätt att göra tidiga val synliga, testbara och genomförbara. Funktioner som inte stöder kärnresultatet för den första releasen dokumenteras som framtida överväganden i stället för att i det tysta läggas till en fast omfattning.

Vem det är för

En App MVP Sprint passar team som:

• Har en definierad produktidé eller ett affärsproblem men behöver hjälp att omsätta det i en realistisk första release
• Vill validera en fokuserad kundresa innan de investerar i en bredare produktplan
• Behöver en ansvarig leveransprocess för produktomfattning, gränssnittsbeslut, utveckling och releaseförberedelser
• Ersätter informella prototyper, kalkylblad eller manuella steg med en första användbar appupplevelse

Vad det hjälper till att klargöra

En MVP-sprint hjälper till att klargöra:

• Vilket användarproblem och vilket primärt flöde den första releasen ska hantera, och vilka idéer som bör vänta
• Vilka antaganden, beroenden, innehåll, integrationer eller kundgodkännanden som behöver lösas innan bygget kan fortsätta
• Vilka funktioner som är nödvändiga för en testbar release och vilka som är önskvärda förbättringar för en senare produktplan
• Vilken testning, vilket ägarskap och vilka releaseförberedelser som är praktiskt möjliga inom den överenskomna omfattningen och tidplanen

Vad ingår

• Skriftlig bekräftelse av omfattningen som beskriver målet för den första releasen, plattform, överenskomna användarflöden och leveransavgränsning
• Fokuserad produkt- och gränssnittsdefinition för de nödvändiga skärmar och interaktioner som ingår
• Byggarbete för de överenskomna MVP-funktionerna, med antaganden och beroenden dokumenterade när de uppstår
• Praktisk testning av de överenskomna användarflödena före överlämning eller releaseförberedelser
• Stöd för releaseberedskap anpassat till den överenskomna plattformen, kontoåtkomsten och ansvaret för inskickning
• Källkod, dokumentation och en överlämningssammanfattning som anger vad som levererades, vad som behöver ägarens input och vad som hör till en framtida fas

Vad som inte ingår

• En obegränsad funktionsbacklogg, obegränsade revideringar eller automatisk inkludering av varje idé som diskuteras under sprinten
• Komplexa backendplattformar, marknadsplatsfunktioner, video i realtid, avancerade dataprogram eller brett regelefterlevnadsarbete om det inte avgränsats separat
• En utfästelse om lanseringstidpunkt, godkännande i App Store eller Google Play, användaradoption, affärsresultat eller oavbruten tredjepartstjänst
• Löpande produktledning, underhåll eller framtida funktionsutveckling efter att uppdraget avslutats, utöver det avgränsade stödet efter lansering för levererade punkter inom omfattningen
• Arbete som beror på innehåll, konton, juridiska beslut, externa leverantörer eller integrationer som inte är tillgängliga eller inte har bekräftats i omfattningen

När det passar att välja den

Välj en App MVP Sprint när den centrala utmaningen är att bestämma vad den första användbara versionen ska vara och sedan leverera den versionen med disciplin. Den kan passa ett team i tidig fas, ett etablerat företag som testar en ny tjänstemodell eller ett team som behöver ersätta en manuell kundprocess med en fokuserad appresa. Den är mest effektiv när det finns en namngiven beslutsfattare, tillgång till de personer som förstår användarproblemet och en vilja att hålla version ett medvetet smal. Den passar mindre bra när produktriktningen fortfarande är mycket osäker, kärnflödet för användaren ännu inte kan beskrivas eller de nödvändiga integrationerna och driftberoendena är okända. I sådana fall kan en discovery- eller produktplansfas vara en mer användbar utgångspunkt innan ett byggåtagande görs.

Vår strategi

Vi börjar med att bekräfta det avsedda resultatet, de primära användarna, plattformen och leveransavgränsningen skriftligt. De tidiga samtalen fokuserar på kärnresan snarare än en lång funktionslista: vad en användare måste kunna göra, vilken information som krävs och vad som skulle göra den första releasen sammanhängande. Vi dokumenterar antaganden om innehåll, integrationer, konton, ansvar för godkännanden och externa beroenden så att de inte senare blir dolda leveransrisker. Under bygget håller vi den överenskomna omfattningen synlig och förklarar konsekvenserna av varje ny begäran innan den behandlas som inkluderad. Testningen bygger på de överenskomna användarflödena och praktiska releaseförhållanden. Vid överlämningen får teamet en tydlig bild av avgränsningen för den första releasen, det utförda arbetet och de punkter som bör flyttas till en senare produktplan eller en separat omfattning.

Vanliga frågor

Relaterade artiklar