Agil utveckling: Vad kännetecknar en bra användarberättelse? INVEST

Användarberättelser utgör hjärtat i agil utveckling. De är det primära bidraget till scrumteamet. De tar användarhistorierna och skapar produktinkrement baserat på att slutföra dessa historier. Tyvärr är det inte så lätt att få användarhistorier rätt.

Du kan få mer information om användarhistorier här:

Produktägarna måste lära sig att skapa användarhistorier som uppfyller teamets behov. För att skapa bra användarberättelser börjar du med att komma ihåg att INVESTERA i bra användarberättelser. INVEST är en akronym som omfattar följande begrepp som utgör en bra user story:

Independent: En produktbakgrundsartikel (PBI) ska vara fristående.

Negotiable: En användarberättelse är en självständig sak som är förhandlingsbar: Det bör finnas utrymme för diskussion.

Värderligt: Måste leverera värde till intressenterna.

Estimable: Du måste alltid kunna uppskatta storleken på en PBI.

Små: Du bör kunna planera, utföra och prioritera den.

Testbar: Utvecklingen ska kunna testas.

Stories ska vara så oberoende som möjligt och du ska kunna arbeta med dem i vilken ordning som helst. Detta gör det möjligt att verkligen prioritera varje enskild berättelse. När beroenden kommer in i bilden är det kanske inte möjligt att implementera en värdefull story utan att implementera andra mycket mindre värdefulla stories.

Negotiable

En bra story är förhandlingsbar och inte ett kontrakt. En bra berättelse är en inbjudan till ett samtal. En bra berättelse fångar essensen av det som önskas. Det faktiska resultatet måste vara resultatet av en samarbetsförhandling mellan produktägaren och utvecklingsteamet. Målet är att tillgodose kundens behov.

Värde

Användarberättelser bör prioriteras i backloggen enligt affärsvärde. Att komma upp med produktbacklog-objekt som är riktigt roliga att koda men som inte ger något värde för intressenterna bryter mot en av de agila principerna, som är att kontinuerligt leverera värdefull mjukvara

Estimable

Utvecklare måste kunna uppskatta en story. Den bör skrivas på ett sådant sätt att utvecklarna kan förstå den och ha en uppfattning om hur den ska genomföras. Nyckelfaktorer för uppskattning är domänkunskap och teknisk kunskap.

Små

Goda berättelser tenderar att vara små, men hur små ska de vara? Svaret beror på teamet och den metod som används. Många produktägare föreslår två veckors iterationer, vilket möjliggör användarberättelser på tre eller fyra genomsnittliga arbetsdagar. Detta inkluderar allt arbete för att få berättelsen till ett ”färdigt” tillstånd.

Testbar

Berättelser bör vara testbara för att hjälpa till att fastställa fullständighet. En berättelse bör ha ett acceptanskriterium. Godtagningskriterierna bör vara objektiva. Undvik att använda kriterier som, lätt att använda, snabb eller felfri. Try to write criteria that can be measured and tested.

Via:

Lämna ett svar

Din e-postadress kommer inte publiceras.