Linköpings universitet 2. Practical agrement. Setting up the room. Definition of Done. Start on product backlog. User story template

Transcription

1 Sprint 0 TDP029 En agil systemutvecklingsprocess Annika Silvervarg COIN/HCCS/IDA (Strategic intake & research) (Product statement) (Design koncept) Technical solution outline Practical agreements Setting up the room Definition of done Start on Product backlog 1 2 Strategic intake & research Market and end-user Competition? Market? End-users? Brand Defined brand? tone-of-voice? Corporate visual identity? Product statement Template: For (target customer) who (statement of need or opportunity) the (product name) is a (product category) that (key benefit, compelling reason to buy) Example: trakz.nl is a trustworthy online music store, we are personal and passionate about music! 3 4 Design koncept Graphic profile Conceptual design Fråga kunden om sådan finns Om inte, diskutera hur det ska hanteras! Technical solution outline Can include legacy system limitations CMS characteristics Database GUI Architecture Viktigt att diskutera detta med kunden! Kan behövas ytterligare en iteration för detta! 6 7 Linköpings universitet 1

2 Practical agrement When do you work? Where do you work? What are the responsibilities of the scrum master? Contact information, , phonenumbers. When do you have stand-up meetings (and how)? When do you demo and test and with whom? When and how do you do the retrospective? Viktigt att göra detta explicit inom gruppen! Viktigt att komma överens tillsammans med kunden om vad som gäller för demo/test! Setting up the room Hardware The room Supplies Software Dropbox GITLab, SVN, Scrumboard Physical, Trello, wiki, excel, google docs, Detta KAN läggas på scrum mastern, men också någon/några andra 8 9 Definition of Done Technical requirements Devices? Browsers? Documentation? How tested? User experience How does it feel? Tests with external people? Customer acceptance Who decides when done is done? Viktigt att diskutera detta med kunden! Start on product backlog The backlog is a prioritized features list, containing short descriptions of all functionality desired in the product, typically in the form of User stories, which are short, simple descriptions of the desired functionality told from perspective of the user "As a shopper, I can review the items in my shopping cart before checking out so that I can see what I've already selected." User story template User story exempel Title (one line describing the story) As a [role] I want [user need] So that/because [resulting ability] OR As a [role] I can [do/view something] Linköpings universitet 2

3 User stories types Epics Back-end Technical Infrastructure Refactoring Bug fixes Spikes Non functional UX Safety, Security, Performance Sustainability A good user story INVEST Independent, of other stories Negotiable, not a contract Valuable, to customer or end user Estimable, enough information and reasonable scope Small, coded and tested within half a day to two weeks Testable, clear definition of done Sprint 0 Att Göra Grupp: Utse en scrum master Grupp: Gå igenom scheman och gör en detaljerad planering för vilka tider gruppen ska jobba. Bestäm ett lämpligt straff för sen ankomst (t.ex. bjuda gruppen på fika) Grupp: Se till att ett möte med kunden äger rum. Utbyt kontaktuppgifter och kom överens med kunden om hur kommunikationen under projektet ska fungera Kund: Delta i möte med projektgruppen och gör en översiktlig beskrivning av det planerade systemet (inklusive syfte, vision). Kund och Grupp: Kom överens om och skriv under avtal Kund: Förbered user stories och förmedla till projektgruppen Grupp: Genomför en tekniköversikt och riskanalys gällande val av teknikplattformar (utvecklingsverktyg, programspråk, databashanterare, etc). Sprint 1-6 Release plan Product backlog Iteration plan Sprint backlog Time estimates Planning poker Velocity Prioritise Scrum board and Burn down chart Daily scrums Use practices from XP for implementation work Demo and Acceptance testing Retrospective Release plan Product backlog The customer presents the desired features for the release in the form of user stories. These form the product backlog The stories can be given business value Developers can also suggest stories The developer estimate the difficulty in term of time to implement each story (in story points or days) The stories can also be given a technical risk Available time for the release is estimated The customer choose which stories to include in the release given the available time The goal is a usable and testable system with busines value to be deliverd as soon as possible Estimating user stories Intuitive time estimates how long it would take if you programmed all days without interruptions, compare the different stories for difficulty Spike solution experiment to get an idea of how a problem can be solved Estimate by comparison compare a story with the previously implemented stories Linköpings universitet 3

4 Planning poker Iteration plan Sprint backlog The cusomter chooses which stories to include in the next iteration Developers break down the stories into tasks, and estimate the time they will take to implement (in hours) Th available time is estimated based on the amount of work completed in the previous iteration The customer chooses and prioritises the stories (and thus corresponding tasks) to be implemented in the iteration, these form the sprint backlog Velocity Available time for stories in the previous iteration: 3*28 h = 84 h Estimated time for finished stories in the previous iteration: 35h Velocity of previous iteration 35/84 = 0,42 = (42%) The first iteration can have velocity 50% (or 0%, which means that the developers do as much work as possible from a prioritised list) Available time for the next iteration Available time: 30h/pers/sprint Number of persons: 5-6 Pairs: 3 Availalbe time : 3*30 h = 90 h Velocity: 42% Total time for stories in ideal hours: 90 * 0,42 = 37h Acceptance test Acceptance tests are created from user stories During an iteration the user stories selected will be translated into acceptance tests by the customer A story can have one or many acceptance tests, each acceptance test represents some expected result from the system Customers are responsible for verifying the correctness of the acceptance tests and decide which failed tests are of highest priority to fix in the next iteration Acceptance test template Scenario 1: Title Narrative: Given [context] (And [some more context]...) When [event] Then [outcome] (And [another outcome]...) Linköpings universitet 4

5 Acceptance test exempel SCRUM Board User story Criteria for acceptance test Burn-down chart Scrum meetings Yesterday I did Today I am going to do I have a problem with XP practices during development Pair up (Pair programming) Write unit test (Test-driven development) Code (Code and Design Simply, Coding Standards) Ask user for clarification (On-site customer) Clean up (Refactoring, Collective code ownership) Check in test and code (Continuous integration, Test.dirven development) Go home after 8 hours (Sustainable pace) Demo and Acceptance tests Short presentation of the process of the sprint (preconditions, constraints, impediments, etc.) Short walk through of the product, explaining decisions made (focus on what, not how) Customer (stakeholders) sit down individually and go through users stories using the system and judge if acceptance tests pass or fail Failed acceptance tests are collected for next iteration Scrum master have closing discussion with customers and bring the most important bits back to the team Linköpings universitet 5

6 Retrospective Retrospective Inspect and adapt Draw a timeline of the sprint on a whiteboard Sit down individually (5 min) Write positive things on green post its Write negative things on pink post its Place the post its on the timeline (2 min) Look at the board and discuss what you wrote to identify patterns or clusters (5 min) Choose max 3 things you want to improve (5 min) Tidsplan och gemensamma övningar V4-5 Sprint 0 V4 To Övning Extreme hour V5 Product backlog från kund klar V6 Ti Övning Planning poker, Genomgång och diskussion inför Sprint 1 V6-7 Sprint 1 V7 Fr kl Demo med kund, kl Retrospective Linköpings universitet 6