Tasuta Agile-meeskondade projekti olekuaruande esitlusmall: mida peaks sisaldama?

Agile-meeskonnad suudavad toota rohkesti tegevusandmeid, kuid jätta sidusrühmad siiski samade põhipõhiküsimustega: Kas oleme õigel teel? Mis muutus? Mis on ohus? Millist otsust minult oodatakse? Kasulik projekti olekuaruande esitlus peaks neile küsimustele kiiresti vastama, ilma et sellest saaks teine backlog, meeskonna ürituste asendaja või tühjade näitajate kogum.

See leht pakub tasuta, kopeerimiseks valmis projekti olekuaruande esitlusmalli Agile-meeskondadele. Saate luua slaidistruktuuri uuesti PowerPointis või mõnes muus esitlustööriistas ning kohandada seda oma toote, projekti, aruandluse rütmi ja sihtrühma jaoks. Eesmärk ei ole panna kõiki meeskondi aru andma samal viisil. Eesmärk on anda teile kerge struktuur, mis teeb edenemise, ebakindluse ja otsused nähtavaks.

Mille otsuse tegemisel peaks see olekuaruanne aitama?

Alustage siit enne värvide, diagrammide või slaidipaigutuste valimist. Olekuaruande esitlus on kasulik siis, kui see aitab sidusrühmal otsustada, kinnitada, takistus eemaldada, prioriteeti muuta, prognoosi aktsepteerida või mõista olulist muutust. Kui sihtrühm saab esitlust lugeda, kuid ei suuda siiski öelda, mis tähelepanu nõuab, on aruanne tõenäoliselt liiga kirjeldav ja mitte piisavalt otsustele orienteeritud.

Agile-meeskonna jaoks on kõige kasulikumad küsimused tavaliselt:

• Kas teeme olulist edenemist praeguse toote- või projekti eesmärgi suunas?
• Mis tulemus või inkrement lõpetati alates eelmisest uuendusest?
• Mis on muutunud ulatuses, ajastuses, riskides või eeldustes?
• Mis on blokeeritud ja kes saab aidata takistust eemaldada?
• Millele keskendub meeskond järgmisena?
• Mis otsus või sidusrühma tegevus on praegu vajalik?

Ametlik Scrumi juhend rõhutab läbipaistvust, kontrolli ja kohandumist. Selles öeldakse ka, et kokkulepitud eesmärkide poole liikumist tuleb sageli kontrollida, et tuvastada soovimatud kõrvalekalded või probleemid. See teeb lühidast olekuaruande esitluse kõige väärtuslikumaks siis, kui see parandab nähtavust ja toetab tegelikku kohandumist, mitte ei dokumenteeri lihtsalt, et töö toimus. Vaadake ametlikku Scrumi juhendit.

Millised slaidid peaksid olema tasuta Agile'i projekti olekuaruande mallis?

Tugev vaikevariant on seitse põhislaidi koos valikulise näitajate lisaga. Väiksemad meeskonnad saavad need kokku võtta kolmeks või neljaks slaidiks. Suuremad programmid võivad lisada detaile, kuid peamine esitlus peaks jääma kergesti skaneeritavaks.

Millist teavet peaks juhtkonna oleku slaidil olema?

Vastage pealkirjaküsimustele enne detailide näitamist. Praktiline juhtkonna oleku slaid mahutab viis elementi: praegune eesmärk, üldine olek, üks või kaks tõenduspunkti, suurim risk ning vajalik otsus või tegevus. Sihtrühm ei tohiks järelduse avastamiseks pidada tõlgendama kuut diagrammi.

Kui kasutate punast/kollast/rohelist olekut, määratlege reeglid. Näiteks võib roheline tähendada, et praegune eesmärk on saavutatav praeguse prognoosi raames ja ühtegi lahendamata probleemi ei pea eskaleerima; kollane võib tähendada, et eesmärk on endiselt saavutatav, kuid oluline risk või sõltuvus vajab aktiivset haldamist; punane võib tähendada, et praegune prognoos või eesmärk ei ole enam usutav ilma muudatuseta. Need on näited, mitte universaalsed Agile'i standardid. Teie organisatsioon peaks valima järjepidevad ja nähtavad määratlused.

Vältige oleku värvi muutmist ainult seetõttu, et koosolek läheneb. Usaldusväärne olekunäitaja peaks peegeldama tõendeid ja teadaolevat ebakindlust, mitte esitlusrõhku.

Millised Agile'i näitajad on olekuaruandes kasulikud?

Kasutage näitajaid, mis selgitavad sellele sihtrühmale edenemist või riske. Trend ja kontekst on tavaliselt olulisemad kui üksik number. Sõltuvalt tööst võivad kasulikud tõendid hõlmata lõpetatud tulemusi, tsükli või läbimise aja trende, läbilaskevõimet, põgenenud vigu, teenuse usaldusväärsust, prognoosi kindlust, kliendi tagasisidet või edenemist toote eesmärgi suunas.

Burndown, burnup, kumulatiivne vool ja sarnased tavad võivad olla kasulikud prognoosimisabivahendid, kuid Scrumi juhend märgib selgesõnaliselt, et sellised tavad ei asenda empiritsismi. Samuti hoiatab, et keerulises keskkonnas on tulevik olemuslikult ebakindel. See on hea põhjus, miks nimetada prognoose prognoosideks ja näidata eeldusi, mitte esitada diagrammi kui kindlust.

Kas kiirust (velocity) peaks slaidile panema?

Ainult siis, kui see aitab kavandatud sihtrühmal mõista meeskonna enda planeerimiskonteksti. Scrumi juhend ei näe ette kiirust kui kohustuslikku Scrumi näitajat. Kui te selle lisate, selgitage, mida see konkreetse meeskonna jaoks tähendab, ja vältige selle kasutamist meeskondadevahelise tootlikkuse edetabelina. Kontekstita number võib kutsuda esile vale otsuse.

Kas esitlus peaks asendama Sprinti ülevaatuse?

Ei. Scrumis on Sprinti ülevaatus töösessioon, kus Scrumi meeskond ja sidusrühmad kontrollivad Sprinti tulemust ja arutlevad edenemist toote eesmärgi suunas. Scrumi juhend ütleb selgesõnaliselt, et Sprinti ülevaatust ei tohiks piirata ainult esitlusega. Olekuaruande esitlus võib toetada vestlust, pakkuda lühikest eellugemist või kokku võtta teavet inimestele, kes ei saa osaleda, kuid see ei tohiks muuta ülevaatuse ühepoolseks aruandluseks.

Septembri 2026. aasta seisuga tuvastab ametlik Scrum Guides'i sait endiselt novembri 2020. aasta Scrumi juhendi kui kehtiva ametliku versiooni. Saate kontrollida kehtivat versiooni ametlikult Scrumi juhendi allalaadimislehelt.

Millist detailide hulka peaks erinevatele sihtrühmadele sisaldama?

Kujundage peamine esitlus inimestele, kes peavad otsuseid tegema või mõjutama. Juhtkond vajab tavaliselt praegust eesmärki, ärimõju, prognoosi, olulisi riske ja otsuspalveid. Toote- ja tarnejuhid vajavad sageli sama kokkuvõtet pluss verstapostide ja sõltuvuste detaile. Meeskond võib vajada sügavamat operatiivset andmet, kuid see teave võib asuda backlogis, armatuurlaual, probleemihalduris või lisas, mitte juhtkonna slaididel.

Lihtne test on eemaldada iga element, mis ei muuda mõistmist või tegevust. Kui slaid sisaldab kakskümmend backlogi elementi, kuid sihtrühm peab teadma ainult seda, et üks väline sõltuvus ohustab verstaposti, võtke sõltuvus kokku ja linkige üksikasjalik jälgimissüsteem, mitte ärge taastootke backlogit.

Kuidas peaks riske ja takistusi esitama?

Ärge piirduge probleemide loeteluga. Iga oluline element peaks näitama, miks see on oluline, mida tehakse, kes vastutab järgmise tegevuse eest ja kas sidusrühma abi on vajalik. Kompaktne riskirida võib kasutada seda struktuuri:

• Risk või takistus: selgekeelne kirjeldus.
• Mõju: eesmärgi, ulatuse, kliendi, kvaliteedi, kulu või ajastuse tagajärg.
• Reaktsioon: leevendamine või järgmine eksperiment.
• Omanik: isik, kes vastutab järeltegevuse eest.
• Vajalik otsus: kinnitus, eskaleerimine, prioriteedi muutus või mitte midagi.

Eristage takistust, mis juba takistab edenemist, riskist, mis võib tekkida. See eristus muudab eskaleerimise selgemaks ja takistab iga muret tundmast võrdselt kiireloomulisena.

Kui sageli peaks Agile'i olekuaruande esitlust uuendama?

Kasutage rütmi, mis sobib sidusrühmade otsustega ja meeskonna tarnerütmiga. Nädalane uuendus võib olla mõistlik kiiresti liikuvate algatuste jaoks, millel on välised sõltuvused. Sprintipõhine uuendus võib piisata, kui Sprint pakub juba õiget kontrollirütmi. Kuu esitlus võib sobida kõrgemale juhtimisele, kui olulisi otsuseid tehakse harvem.

Scrumi juhend ütleb, et Sprintid on fikseeritud pikkusega üritused, mis kestavad ühe kuu või vähem, ja et regulaarsed Scrumi üritused loovad võimalusi kontrolliks ja kohandumiseks. See ei tähenda, et iga Scrumi meeskond vajab eraldi nädalast olekuaruande esitlust. Vältige aruandluse loomist, mis dubleerib teavet, mis on juba mujal nähtav ja mõistetav.

Mis muudab selle esitluse korduvkasutatavaks malliks, mitte ühekordseks esitluseks?

Hoidke struktuur stabiilsena ja sisu asendatavana. Kasutage järjepidevaid kohatäitjaid aruandlusperioodi, praeguse eesmärgi, oleku kokkuvõtte, riskitabeli, verstaposti prognoosi ja otsuspalvete jaoks. Pange püsivad visuaalsed reeglid, nagu logo paigutus, tüpograafia, jalus ja standardsed paigutused, esitluse malli, mitte ärge ehitage neid iga tsükli järel uuesti üles.

Microsoft dokumenteerib, et PowerPoint saab alustada ettevalmistatud mallidest ja et töölaua PowerPoint saab salvestada korduvkasutatavaid malle .potx failidena. Selle toejuhised selgitavad ka, et slaidi masterit ja slaidipaigutusi saab kasutada korduvkasutatavate kohatäitjate loomiseks. Vaadake Microsofti PowerPointi esitlusjuhiseid ja Microsofti juhiseid PowerPointi malli loomiseks ja salvestamiseks.

Kui töötate PowerPointi veebiversiooniga, ütleb Microsoft, et saate luua esitlusi mallidest, kuid selle praegune malli loomise toe leht märgib, et korduvkasutatava PowerPointi mallifaili enda loomine nõuab töölauaversiooni. See piirang on oluline, kui teie eesmärk on tõeline .potx mall, mitte esitlus, mida te kopeerite käsitsi.

Mida peaksite enne malli esitlemist muutma?

Asendage üldised sildid keelega, mida teie sidusrühmad tegelikult kasutavad. Tehke praegune eesmärk selgeks. Eemaldage kasutamata näitajad. Määratlege oleku värvid. Kontrollige kuupäevi ja omanikke. Seejärel tehke otsuspalved konkreetseks: selle asemel, et kirjutada “Vajab toetust”, kirjutage, milline otsus on vajalik, kes peab selle tegema ja millal.

Samuti eristage fakte prognoosidest. “Kolm funktsiooni vastasid Valmisoleku definitsioonile” on väide lõpetatud töö kohta, kui teie meeskond on selle kinnitanud. “Väljalaske ootus järgmisel kuul” on prognoos ja peaks sisaldama asjakohaseid eeldusi või kindlust. Nende kategooriate eristamine aitab lugejatel mõista, mis on teada versus mis võib muutuda.

Kuidas saate teada, kas olekuaruanne töötab?

Pärast uuendust kontrollige tulemust, mitte slaidide välimust. Kasulik aruanne peaks võimaldama lugejal vastata praeguse eesmärgi, kõige olulisema edenemise, peamise riski, lähiaja prognoosi ja järgmise otsuse küsimustele ilma eraldi selgitust küsimata.

• Kas sihtrühm suudab tuvastada ühe või kaks probleemi, mis vajavad tähelepanu?
• Kas nad näevad, mis on muutunud alates eelmisest uuendusest?
• Kas lõpetatud tulemused on eraldatud prognoosidest?
• Kas riskid on paaris omanike ja reaktsioonidega?
• Kas otsuspalved on selged?
• Kas esitlus väldib üksikasjalike backlogi andmete dubleerimist, mis peaksid olema mujal?
• Kas see toetab kontrolli ja kohandumist, mitte ei muuda Agile'i üritusi olekuteatriks?

Kui vastus mitmele neile küsimustele on ei, lihtsustage esitlust enne rohkemate diagrammide lisamist. Parim projekti olekuaruande esitlusmall ei ole see, millel on kõige rohkem slaidi. See on see, mis loob piisava läbipaistvuse, et õiged inimesed saaksid olukorda mõista ja teha järgmise kasuliku otsuse.