T Sprint Demo Team Tarantino Iteration 1 / Sprint

T Iteration demo 2 Agenda  Project status (10 min)  Achieving the goals of the sprint  Project metrics  Realized risks  Work results (15 min)  MUPE status  Wiki status  Used work practices (5 min)

Introduction

T Iteration demo 4 Introduction to the project  Quentin primary goal is to agilize movie’s production stages.  It is a modern tools for collaboration.  Amount of information that is gathered during pre-production is huge  During production coherent information is vital since shots can be filmed in middle of nowhere. A simple misunderstanding can become very expensive!  Crew can get more tailored information

T Iteration demo 5 Project plan: Development process  Iterative process  Two development iterations, each divided into two sprints  Sprint contents  Planning phase, overlaps with the previous sprint  Development phase, features for this sprint are frozen  Integration phase, the implemented features are verified  Sprint planning  Features to be included are agreed with the customer at the start of the sprint  Kick-off meetings with the whole team at the beginning of each sprint  Reflection workshop at the end of each sprint, process improvement Project Planning Iteration 1Iteration 2 Holiday Sprint 1Sprint 2 Sprint 4Sprint 3 Colors: Planning Defeloping features Integrating features S1 S2 S3 S4 S3 S2

Project status

T Iteration demo 7 Status of the S1s deliverables  The first version of the MUPE reader  OK, still some problems when using with real device  The first version of the modified Wiki  OK, some minor bugs to be fixed  Updated version of project plan and requirement document  Not OK, formal versions of project plan and requirement document will be produced only at the end of S2  QA Plan  OK  Progress report  OK  Test reports  OK

T Iteration demo 8 Status of the S2’s deliverables  The first version of the MUPE-io  OK  The second version of the modified Wiki  Quite OK: Bold goals for S2 not fully realized, but technically challenging core functionality in place.  Updated version of project plan and requirement document  OK  QA Plan  OK  Progress report  OK  SEPA diaries  OK?  Test reports  OK

T Iteration demo 9 Realization of tasks (S1)

T Iteration demo 10 Realization of tasks (S2)

T Iteration demo 11 Resource usage  Project is on its track but under its budget  Lower than expected resource usage in the S1 & S2 will give us more slack for the rest of the project  The challenge is to use this slack: => Holidays can be utilized. Original plan (in the beginning of the iteration) Realization and updated plan (realized hours and updates) , ,571 I ,51516,521,5 S Total 202, ,527 S ,539,533,54351,571 PP SUMRBTPLKJHTHTNJM ,573,581,57773,559 I ,533 S Total 202, ,527 S ,539,533,54351,571 PP SUMRBTPLKJHTHTNJM

T Iteration demo 12 Quality dashboard  Documentation extensively reviewed and updated  Wiki: Use cases selected for implementation have been tested, some minor defects open  MUPE: Explorative testing performed, usability not yet sufficient  Code reviews behind schedule, customer comments needed Legend Confidence: 3 = tested well 2 = tested 1 = looked at, but uncertain 0 = not tested at all Quality: 3 = quality is good 2 = quality is mediocre 1 = quality is bad

T Iteration demo 13 Quality Metrics 1/2  Defect status:  Most defects logged are minor cosmetic defects or usability notes  No critical defects logged, testing during development sufficient  High severity TR029_MUPE: Old MUPE login does not work after server restart, almost showstopper, but has a workaround

T Iteration demo 14 Quality Metrics 2/2  Codebase size in LOCC (revision 304):  Other metrics and practices:  Statistical metrics for the Generic Wikireader for MUPE:  Heuristic evaluation of usability for Wiki and MUPE brought many improvement suggestions  Explorative testing and extensive testing during development

T Iteration demo 15 Realized Risks  RI003: A team member may lack the skills needed in the project.  Effect: A developer had challenges in getting started with his work. (S1, severity: High)  Effect: A bottleneck task was almoust complete for several days during. (S2, severity: High)  RI004: Communication between group members might be insufficient.  Effect: PM was unaware of problems that one developer had. (S1, severity: Medium)  RI007: Project servers might be down for a while.  Effect: Wiki was not in use for a while. (S1, severity: Low)  RI009: There might be problems with communication channels.  Effect: See above.  RI013: Sprint time schedule might be unrealistic.  Effect: Some tasks were clearly late and the development had to be continued parallel during the testing. (S2, severity: High  RI014: Bottlenect tasks might hinder the project progress.  Effect: See RI003  RI019: Making modifications to Wiki might be unexpectedly challenging  S1 & S2 came a bit short of what was planned.

Work results

T Iteration demo 17 Wiki status  Implemented:  Data structure has been designed  The most technically challenging functionality has been implemented  Many kinds of special pages  Commenting functionality  Shot scheduler  Drag-drop sorting  Basic call-sheet functionality  To be implemented:  Call sheet to be finalized  Version history  GUI and navigational structure to be finalized based on customer comments  Lots of work in here!

T Iteration demo 18 MUPE status  Implemented:  Transfer WikiText to MUPE  Working links  Dividing article to subpages  Upload: Commenting functionality & photo sending  To be implemented:  MUPE-parser: Usability & Heuristics  Authentication?

Used work practices

T Iteration demo 20 Most important work practices  Time reporting (Excel-sheets)  Status reporting:  Backlog used as a part of status reporting => wasn’t of much use, since S1 there was no budget pressure  Communication  Few face-to-face meetings used in S1, Many Skype meetings in S2  Challenges in communication during S1 => Regular Skype meetings solved this problem in S2.  Documenting  All the documents in team Wiki, has functioned well  Document version control in Wiki  Early victory  "Easy thing first, the most business critical second" turned more into "Easy thing first, the hardest second”, but was nevertheless a useful approach  Process improvement  What did we learn?  Which methods were worth using and which were not?  What problems did we have?  Whas the problem caused by us or some other stakeholder?  What can we do better?  Which methods should be try using in the next sprint?

S3 Goals

T Iteration demo 22 S3 Goals (to be discussed with the customer)  Finalizing the functionality currently under work in Wiki + new requirements received from the customer  Enhance the usability of both MUPE and Wiki GUI so that the first ”production” version of the software would be ready at the end on S3  Continue SEPA work

Thanks for your interest! Questions?