Miðannarverkefni Tilgangur Að nemendur hafi innsýn í undirbúning á hugbúnaðarþróun með Scrum. Verkefnislýsing Verkefnið snýst um að setja upp skipulag og skilgreiningu verkefnis að eigin vali með Scrum aðferðinni. Uppsetning og skipulag (Organization planning) 1. Fyllið í Scrum hlutverkin innan hópsins. Scrum master, product owner og þróunarteymi. Product owner ætti að vera sá í hópnum sem hefur mesta innsýn á því sviði sem verkefnið liggur á. 2. Ákveðið hvaða aðferð skal notuð til að halda utan um áætlun spretts, og hvernig daglegir fundir fara fram í því samhengi. Rökstyðjið val ykkar. 3. Lýsið vinnulagi sem þið hyggist beita, staðsetningu einstaklinga í hópnum, hvernig samskipti munu eiga sér stað. 4. Ákveðið lengd spretta. Skilgreining vöru (Release planning) 1. Komist að samkomulagi um verkefni sem á að skipuleggja, og vinnið sýn fyrir verkefnið, notið lyfturæðu sniðmátið ("Elevator pitch"). 2. Greinið notendahlutverk í verkefninu með User Role Mapping. Skrifið stutta lýsingu á hlutverkum. 3. Skrifið minnst 10 sögur, notið sniðmátið frá Mike Cohn. Munið eftir viðskiptalegum tilgangi. Allar sögur í fyrsta sprett þurfa að hafa viðtökupróf skilgreind (athugið tengsl við lið 2 í Framkvæmd þróunar). Setjið sögurnar upp í forgangsraðaðan lista ("Product backlog"). Munið að vörueigandinn (product owner) hefur úrslitavald um forgangsröðun. 4. Metið allar sögur með sögupunktum. Stærðarmetið sögurnar sem teymi með "story points", ekki verra að nota áætlunarpóker (planning poker). 5. Reiknið áætlaðan þróunarhraða ("Velocity") með því að nota “Forcast method”. (athugið tengsl við lið 1 og 2 í Framkvæmd þróunar). 6. Reikna áætluð verklok miðað við áætlaðan þróunarhraða og setjið upp "Release burndown" 7. Bónuspunktar: Framkvæmið áhættugreiningu og setjið saman lista yfir helstu áhættur sem þið sjáið í þróunarverkefninu. Framkvæmd þróunar (Sprint planning) 1. Setjið upp rýmisáætlun ("Capacity plan") sem sýnir framlag einstaklinga í teyminu fyrir fyrsta sprett. 2. Veljið sögur til að vinna að í fyrsta spretti (út frá þróunarhraða), og brjótið niður í verkþætti. Áætlið alla verkþætti í klukkustundum. 3. Setjið upp “Sprint backlog” og “Sprint burndown”. Skilin eiga að gera ráð fyrir að fyrsti sprettur sé hálfnaður, og framvinda í verkþáttum samkvæmt því. Gerið ráð fyrir að a.m.k. einn verkliður hafi reynst óþarfur og hafi verið hent út, og einn nýr komið í ljós sem menn sáu ekki fyrir. Setjið ritin upp miðað við þessar forsendur. Framkvæmd verkefnis (Retrospectives) 1. Horfið í baksýnisspegilinn (e. perform a retrospective) fyrir framkæmd verkefnisins. Hér er átt við vinnuna við skilaverkefnið, ekki þróunarverkefnið sem er verið að skipuleggja í skilaverkefninu. Teymið ræður forminu, niðurstöður og aðgerðapunktar skulu koma fram í skýrslunni. Skilaform Skilin eru fjórar skýrslur skv. flokkunum hér að framan sem innihalda allt það sem búið var til við framkvæmd verkefnisins. Ef um er að ræða töfluteikningar eða notkun á miðum eða þess háttar, má taka myndir og hafa þær með. Þær þurfa þá að vera nægilega góðar til að hægt sé að lesa allt sem kemur fram. Ef hópurinn vill skila einhverju inn sem er ekki á tölvutæku formi, látið þá kennara vita tímanlega, áður en kemur að því að skila verkefninu. Skýrslunar eiga að vera á PDF sniði en ef það eru fylgiskjöl mega þau vera á því sniði sem hentar best. Einkunn Einkunn verður gefin eftir gæðum afurða sem koma fram í skilum. 0 í einkunn ef ekki skilað innan frests. Mid-­‐term assignment Purpose/Goal For students to have a clear insight into the preparation of developing software using Scrum. Assignment description The assignment is about defining and planning development of a software product of your own choice. Organization planning 1. Fill the Scrum roles within the team, Scrum master, product owner and development team. The Product owner should be the one in the team that has the deepest insight into the domain of the product. 2. Decide how the sprint plan is presented and maintained, and how daily scrum meetings are conducted in that context. Support your decision with arguments. 3. Describe your working agreement, team member locations, and how communication between team members takes place. 4. Decide sprint length. Product definition (Release planning) 1. Establish a consensus on the product to plan development for, produce a vision for the product, use the elevator pitch template for this purpose. 2. Map the user roles in the product. Write short description for each role. 3. Write at least 10 stories, use the template from Mike Cohn. Remember business purpose. All stories planned for first sprint have to have acceptance criterias defined (this relates to item 2. in Development execution). Organize the stories in a prioritized list (Product backlog). Remember that the Product owner has the final say on prioritization. 4. Estimate all stories using story points. As a team, collaborate on the estimating using story points, we advise to use Planning Poker. 5. Calculate estimated velocity using the forecast method (this relates to item 1 and 2 in Development execution). 6. Calculate estimated release date using estimated velocity and create a release burndown. 7. Bonus points: Perform a risk analysis and create a list with top risks you foresee in the product development. Development execution (Sprint planning) 1. Create a capacity plan which shows the estimated effort by each individual in the team for the first sprint. 2. Select stories to work on in the first sprint (based on velocity), and break down into tasks. Estimate each task in hours. 3. Create sprint backlog and sprint burndown. The assignment hand in should assume that you are half way through the first sprint, and task progress is according to that. Imagine that at least one task turned out to be unnecessary and was discarded, and one unforeseen task emerged. This should be explicit in the diagrams. Assignment execution (Retrospectives) 1. Perform a retrospective for the assignment execution. This is about your collaboration on this school assignment, not the development project you are planning. The team decides the form, results and action points shall be presented in your assignment report. Return form The return form is four reports representing the chapters above, the reports should contain all artifacts created during the assignment execution, or a representation of them. If you have sketches on a whiteboard, or use of stick-­‐it notes or other forms of paper, you can take a picture and use that. In this case, the picture quality must be sufficient so everything on the picture is legible. If you want to turn in something in non-­‐digital form, please let the teacher know well in advance of the deadline. The reports need to be in Pdf format, if there are attachments you can use the appropriate format. Grading The grade is determined by the quality of the artifacts that are presented in the report. 0 will be given if the assignment is not turned in before the deadline.