We are currently polluting JIRA with hundreds of tickets that serve no purpose other that to mark someone as a Firefighter or on Discovery Duty. Each sprint we create a new set of tickets, and I’m struggling to see a benefit for this. I don’t remember there ever being any discussion on these tickets, we never log time on them, so they have very little purpose.
The very minor purpose they serve is as follows:
- They block time for the person on discovery duty or firefighter duty
- They are a reminder to the developer that they are Firefighter or on Discovery duty.
- They are a reminder to others about who is on DD and FF.
For the first point, I would contest that since we use Sprints/Sprintcraft for checking sprint commitments, it can simply add the FF or DD time without needing a ticket for it.
For the second and third ones I feel there are other ways of accomplishing that, such as 1) highlighting the FF and DD candidates on Sprints, 2) Making Crafty announce them on MM each sprint, etc. I’ve always looked up the FF on the calendar, and for DD it usually isn’t important to know for everyone.
We can easily do away with these tickets if we simply take the time into account in other ways and highlight who has these roles. However, alternatively if we DO want to have these tickets, there is no reason we need to create a new ticket each sprint, we can:
- Simply have crafty update the estimate on each developer’s personal FF ticket based on their roles.
- Have a single ticket that’s rotated between people each sprint, and crafty will simply change the assignee to who has the role.
Do tell me if I’m missing some other role these tickets serve that wouldn’t be covered by the above.
I know we’re looking to move from Jira so it’s a good time to consider what we’ll migrate and what processes we can change when we have to do some integrations from scratch.
to this idea, but I’m ok with continuing to use the calendar or OpsGenie roster to figure out who’s FF.