Historisk: Detaljeret gennemgang af scoping

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.  

En bug indeholder også:

• 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 blive implementeret under en release. Den er identificeret ved et Release Plan Id som AMS fastlægger. En Feature har såleden en 1 til 1 kobling med AMS’s release Excel ark.

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.  

En feature indeholder også:

• 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.

En task indeholder også:

• 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:

1. Et specifikt forretningsmæssigt domæne f.eks. Til og afmelding. Domæner er defineret ud fra den fælles datamodel og en forretningsmæssig opdeling af service.
2. Et større tværgående initiativ der berører flere domæner f.eks. førtidspension og fleksordningsreform.

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.  

En user story indeholder også:

• 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