Bug
En konkret fejl der er registeret.
Indhold
Beskrivelsesmæssigt består en bug af det samme som en user story og der er beskrivelse af fejlen samt de tilhørende acceptkriterier. Til en bug vil der ofte være en reference til den FogBugz sag. Er der en reference til FogBugz er det der alt indeholde er samlet.
...
- Et Area, der henviser til et konkret systemelement i implementeringen. Overordnet angiver Area således også hvilket overordnet systemråde en feature tilhører, her skelens mellem DFDG online, Integrationsplatform, SharePoint og Planner.
- Severity, der angiver alvorlighed af fejlen dvs. om det er en K1, K2, K3 eller K4.
- Assigned To, kan angives hvis det er relevant at knytte en bestemt person.
- Effort, anvendelse er beskrevet seperat.
- Links til
- Task, angivet som child link
- Test cases
Livsforløb
Livsforløbet for en bug er styret af PO og DFDG teamet. Den fødes i New når den opdages og registreres i FogBugz. Når PO har godkendt den vil det blive Approved. Når en bug tages ind i et sprint bliver den Comitted af DFDG teamet. Når alle tasks på en bug er implementeret sættes den automatisk til Done.
Feature
Feature er et konkret forretningsmæssigt område AMS ønsker implementeret og som giver AMS en forretningsmæssig værdi.
...
En feature vil altid være koblet op på et tema.
Indhold
Beskrivelsesmæssigt består en feature primært af den forretningsmæssige beskrivelse og de tilhørende acceptkriterier. Til featurens beskrivelse kan der så være linket eller uploadet en række uddybende dokumentation som f.eks. et projekt initierings dokument (PID), bekendtgørelser, lovgivning eller notatet.
...
- Et Area, der henviser til et konkret systemelement i implementeringen. Overordnet angiver Area således også hvilket overordnet systemråde en feature tilhører, her skelnes mellem DFDG online, Integrationsplatform, SharePoint og Planner.
- Release, der henviser til den konkrete AMS release featuren laves og produktionssættes i.
- Release Plan Id, der er reference til AMS’s releaseplan i Excel.
- PO, der angiver hvilken Product Owner i AMS der ejer featuren.
- Links til
- Tema, angivet som parent link.
- User stories på featuren, angivet som related link.
- Relase dokumentation, angivet som hyperlink.
Livsforløb
Livsforløbet for en feature er styret af CPO. Den fødes i New og når CPO har godkendt den, vil den blive Approved. Når featuren er implementeret og klar til at blive lagt i produktion sættes den i Done. Det er CPO der tager denne beslutning.
Da en feature automatisk medtages i den release der er angivet, vil den først fremgå af releaseplanen som klar når den er sat i Done.
Feature readyness checkliste
Denne checkliste er for feature og evt. tema klargøring. Fremdriften følges af forretningsarkitekten.
Scopeafklaring
Den initiale afklaring omkring tema og tilhørende features. Dvs. hvordan skal temaet opdeles i features og hvordan skal de indgå i de kommende releases.
Deltager: CPO og forretningsarkitekt
Forretnings Flow og afhængigheder
Flow der omfatter alle grupper/scenaier/tilstande. Identifikation af hvilke grænsesnit og afhængigheder der er mellem DFDG og interessenter (Jobnet, KSS, BI, 4. kt m.f.).
Deltager: CPO, AMS arkitekt, DFDG arkitekt og forretningsarkitekt
Forretningsregler
Specifikke forretningsregler, f.eks. i form af fravær og fritagelses Excel arket, der kræver specielt fokus identificeres og afklares.
Deltager: PO, AMS forretningsarkitekt og forretningsarkitekt
Initialt WS design
Identifikation af hvilke WS der berøres og fastlæggelse af hvordan ændringer overordnet skal udmøntes.
Deltager: AMS arkitekt, AMS forretningsarkitekt, DFDG arkitekt og forretningsarkitekt
LandsSupportSystem (LSS)
Afklaring omkring der skal etableres LSS skærme og aftale rudimentær UX.
Deltager: CPO, Landssupporten og forretningsarkitekt.
Scopetilpasning gennemført
Tilpasning af scope for featuren, dvs. hvad der skal med, ikke med og skydes til senere samt ambitionsniveau for det der skal med.
Deltager: CPO, PO og forretningsarkitekt
Løsningsvurdering
Ud fra forretningsflow og beskrivelse samt initielt WS design en risici vurdering af løsningen i relation til det eksisterende system, grænseflade m.v.
Deltager: AMS arkitekt, DFDG arkitekt og forretningsarkitekt
WS design gennemarbejdet og godkendt
Deltager: AMS arkitekt, DFDG arkitekt, evt. NNIT arkitekt og forretningsarkitekt
Forretningsbeskrivelse godkendt
Godkendt løsningsbeskrivelse, grænsefladebeskrivelse og andre artifakter
Deltager: PO
Forretningsmæssig prioritering
En forretningsmæssig vurdering af vigtighed samt prioritering beskrevet.
Deltager: PO
Gennemgået af DFDG team (Spike)
Løsningsbeskrivelsen gennemgået af DFDG team med henblik på feedback og behov for yderlige afklaringer.
Deltager efter behov: PO, AMS arkitekt, AMS forretningsarkitekt, DFDG arkitekt og forretningsarkitekt
User story landskab
Som grundlag for at få User Stories til at blive skåret rigtigt, gennemtænkes alle senarier, grænseflader, serviceaftagere m.v.
Deltager: Forretningsarkitekt
Fokus
Fokus er de overordnede emner AMS har prioriteret til udførsel i et sprint. Et fokus er knyttet til en eller flere user stories/bugs og bruges primært i grooming og sprint planlægningen.
Indhold
Et fokus består af en overskrift og evt. en kort beskrivelse samt det sprint den er knyttet og den prioritet den har i sprintet. Derudover er der links til de user stories/bugs der høre til det pågældende fokus.
Livsforløb
Livsforløbet for et fokus er tæt knyttet til et sprint og vil død når sprintet er afsluttet.
Sammenhæng mellem scoping elementer
Sammenhængen mellem de nødvendige entiteter er illustreret i nedestående figur.
...
Den fysiske understøttelse af de forskellige entiteter sker i Microsoft Team Foundation Server (TFS).
Task
En konkret opgave der er registeret på en user story. Det er DFDG teamet der opdeler en user story i tasks, så normalt vil scoping fasen ikke se på dette niveau. Dog kan der undtagelsesvis fra scopingfasen være sat tasks på en user story, hvis det er relevant input til nedbrydningen i DFDG teamet.
Indhold
En task består af en sigende titel, en uddybende beskrivelse og tilhørende acceptkriterier. En task vil altid være registeret på én og kun én user story.
...
- Et Area, der henviser til et konkret systemelement i implementeringen. Overordnet angiver Area således også hvilket overordnet systemråde en task tilhører, her skelens mellem DFDG online, Integrationsplatform, SharePoint og Planner.
- Assigned To, kan angives hvis det er relevant at knytte en bestemt person.
- State, der angiver om opgaven er 'To Do', 'In Progress' eller 'Done'.
- Remaining work, der angiver hvor maget der er tilbage af opgave inden den er 'Done'.
Livsforløb
Livsforløbet for en task er styret af DFDG teamet. Den fødes i 'To Do' når teamet laver sprint planning. Når tasken påbegyndes sættes den i 'In Progress'. Når tasken implementeret sættes den til Done.
Tema
Tema er den overordnede forretningsmæssige opdeling af AMS’s initiativer. Temaet tager udgangspunkt i:
...
Temaer kan leve på tværs af flere releases.
Indhold
Et tema består primært af en kort forretningsmæssig beskrivelse. Hvis relevant kan acceptkriterier også angives. Temaets funktion er således at være container for en eller flere features, der både kan går på tværs af forretnings domæner såvel som det kan leve over flere releases. Således kan forretningen herunder CPO have et overblik over alle de elementer der skal håndteres og implementeres, for at et givent initiativ er understøttet i DFDG.
Livsforløb
Livsforløbet for et tema er styret af CPO. Det fødes i New og når CPO har godkendt det, vil det blive Approved. Når temaet er fuldt understøttet og ikke mere er relevant kan det sættes i Done. Det er CPO der tager denne beslutning.
User Story - Product Backlog Item (PBI)
Følger en standard Scrum definition.
En user story kaldes i Microsoft Team Foundation Server sammenhæng for et Product Backlog Item (PBI).
Indhold
En user story består af en beskrivelse og de tilhørende acceptkriterier. Til user story kan der være linket eller uploadet en række uddybende dokumentation.
...
- Et Area, der henviser til et konkret systemelement i implementeringen. Overordnet angiver Area således også hvilket overordnet systemråde en user story tilhører, her skelnen mellem DFDG online, Integrationsplatform, SharePoint og Planner.
- Release, der henviser til den konkrete AMS release user storyen laves og produktionssættes i, denne arves fra featuren.
- Release Plan Id, der er reference til AMS’s releaseplan i Excel, denne arves fra featuren.
- PO, der angiver hvilken Product Owner i AMS der ejer den pågældende user story, dette arves fra featuren, men kan ændres.
- Kontering, der er AMS’s opdeling i typen af arbejde der foretages. Har værdierne foranalyse, udvikling, test og idriftsættelse eller vedligeholdelse.
- Assigned To, kan angives hvis det er relevant at knytte en bestemt person.
- Effort, anvendelse er beskrevet seperat.
- Links til
- Feature, angivet som related link.
- Task, angivet som child link.
- Relation til andre user stories, angivet som predessor eller succesor.
- Test cases.
Livsforløb
Livsforløbet for en user story er styret af PO og DFDG teamet. Den fødes i New og når PO har godkendt den, vil den blive Approved. Når user stories tages ind i et sprint bliver de Comitted af DFDG teamet. Når alle tasks på en user story er implementeret, sættes den automatisk til Done.
Hvis en user story ikke bliver færdigimplementeret i et sprint, sættes den tilbage på backloggen ved at sætte den i Approved.
User Story readyness checkliste
Denne checkliste er for feature og evt. tema klargøring. Fremdriften følges af forretningsarkitekten.
WS eller LSS design intern godkendt i Visma
Design for WS eller LSS gennemgået og godkendt som klar til implementering.
Deltager: DFDG arkitekt og forretningsarkitekt
WS eller LSS design AMS godkendt
Design for WS eller LSS og godkendt af AMS
Deltager: PO, DFDG arkitekt og forretningsarkitekt
Acceptkriterier fastlagt
Deltager: PO og forretningsarkitekt
Estimeret
Estimering inklusiv angivelse af usikkerhed
Deltager: DFDG arkitekt, forretningsarkitekt og DFDG Team
Løsning afklaret/skitseret
Konkret løsningsmodel fastlagt og user story er klar til implementering i sprint (Spike)
Deltager: DFDG arkitekt, forretningsarkitekt og DFDG Team
...