Our baby has grown so fast

Meeting agenda

SLA & Resources

Support two versions - 3.x and 2.6.x*

*we want to force the clients to sign for 3.x but if there are nasty situations we may need to fix

Proactive and reactive maintenance

commitment = availability - planned maintenance
take upfront commitment (time) for maintenance
decide each sprint what to do with the maintenance time if no incidents come in (dev or fix)
if big incidents come in we may have to surpass the M time and risk not closing the commitment

Recommend a default of 2 days per sprint for maintenance each sprint

Client Bug

2nd line

Not a code issue

FIX!

helpdesk procs

code issue

Ticket format

Dev team can fix

FIX!

incorrect ticket

Dev team needs extra support

Just the two of us

FIX!

Client Bug

2nd line

Not a code issue

Useless shift of focus

helpdesk procs

code issue

Ticket format

Dev team can fix

Late fix

incorrect ticket

Dev team needs extra support

Just the two of us

Late fix

Ticket format

clear title beginning with affected municipality
version on which it reproduces
user role with which it reproduced
description with step by step of how to reproduce, expected result and actual result
if available, inputed data from the network
if available, errors form the console
the time of the bug occurrence as precise as possible (in Netherlands time zone)
printscreen
error message (if available)
is it a consistent behavior (reproduced several times in a row)?
credentials to access the affected municipality

Ticket example

we are expecting a lot of bugs to come this first period and dev will be severily impacted
until 2nd line is up and running we will need to invest more time in issues
if clients don't sign quick for the 3.x we'll need to support to versions which will further detract from our delivery focus
we've had issues in the past with communication with PRLG colleagues - have ownership on this (Rudy) so we make things moving quick if we are blocked when fixing an incident

Debate & Q & A