Issue types for SRE teams

[Dionei Piazza]

Hello!

We have a SRE team here at the company.

I'm proposing that we don't use Story-type work items. Since we only work with incidents (bugs) and tasks, I don't understand the Story type as necessary.

In a conversation, the SRE team brought that eventually, we make small changes to a Dashboard solution that we have in the SRE team.

So, here i thought "well, in this case, any new functionality to this dashboard solution should be done through a Story".

Well, considering your experience, would you have any tips, suggestions or alerts to give me?

[Mehmet A _Bloompeak_]

Hi Dionei,

In my experience, in our team SREs mostly work on bugs and tasks. Some of the tasks are solely infrastructure related routines e.g. applying a security patch or renewing ssl certificates. Some tasks are part of a user story e.g. provisioning elastic search that is required for brand new search story being developed by the developers.

However, SREs can also work on their own stories e.g a cost-cutting story on infrastructure which directly has a business value.

Team setup is also important. In our team there was no separation between devs and SREs. They were all part of the same team. Both were working on the same jira project with the same issue types, bug, task, story. We setup the team structure and the jira project structure inline with our product. One team and one jira project for each product.

There was no difference between a UI dev, backend dev and a SRE in the way they work on jira items. Product might have stories which might require solely UI work or solely infra work or both. If a story requires more than one competency(E.g UI and Infra), we create 2 separate tasks under the story one for UI and one for Infra.

[Jack Brickey]

For me Story is a unique way of describing work and should adhere to the following summary format.

As a xxx-user I would like to be able to do yyy

It is an expressive way of describing in conversational language the desired outcome. Stories focus on who the change is for and often express the why in the details. The implementation approach is left to the developer/designer.

Tasks are more specific and more of a directive - "go do this".

Examples:

Story - As an admin of Jira I would like to be able to rearrange filters in the filter list

Task - Change the create button to be at the bottom

I use both all the time.

[John Funk]

Hi Dionei,

For me, Story is too generic. We have lots of different Issue Types that are more descriptive of the work that we do. That way we can track lead time by work item type (issue type) instead of saying everything is a Story. 

We also due straight Kanban and not Scrum, so that might make a difference for some people.