Using a Scrum board for JSD

[Kris Siwiec]

Generally, we take the approach of keeping JSD tickets separate from implementation which might happen in JIRA Software.

I wondered if anybody has set up a Scrum board for a JSD project (or even multiple projects spanning JSD/JSW projects) so that PMs can take advantage of iterative planning - for e.g. for change implementation.

[Kris Siwiec]

Thanks both! Useful to hear your thoughts.

I guess the downside to using a Scrum board which may span multiple projects (JSD + JIRA Software) and multiple workflows is that the board might have a complex config (e.g. lots of issue types, statuses etc.). 

Apart from that, not sure there are any downsides.

[Jack Brickey]

The biggest down side, in my case, is that my JIRA SW team members must be JSD agents which increases cost. This should not be the case and Atlassian should allow users w/ JIRA SW licenses to be agents at no additional cost. Otherwise, IMO, it is double-taxation.

[Nigel Rochford]

JIRA SW team members could be added as collaborators though - i.e. they can internally comment but not communicate with the customer. So no increase in license fee.

[Jack Brickey]

Yes collaboration is indeed possible and as you mentioned no additional cost. However, if you add the issues to the scrum board and cannot assign the actual developer to the task then it is only a partial solution. If the developers are not agents then they can only add comments so the scrum world would look something like this:

1. JSD ticket assigned to Agent_1 and placed into sprint showing up in 'To Do' column on scrum board.
2. Developer_3 is ready to work on the issue so they add a comment 'starting work'
3. Agent_1, seeing the comment would be responsible for dragging the issue to 'In Progress'
4. Developer_3, upon completion of the work, adds comment 'issue resolved'
5. Agent_1 drags the issue to the done column

That is the simple process too. If you want to start considering task estimation and logging work, one of the key components of scrum, then it becomes even messier if the developers are not agents.

[Jack Brickey]

I have been considering this very approach but not yet settled on it. In my organization the IT team is made of of traditional IT support engineers and a small development team that is responsible for the development of some internal business applications that tie into our ERP system. My plan on SLA is that I will add a new status (Development) for any product issues that come into the JSD project. When an issue is moved to that status the IT SLA timer will pause and a new SLA Development metric would kick off. At this point I am contemplating whether we will include the JSD project into our scrum boards or if we will clone the JSD issue and move to the development project. There are pros/cons to each approach, the biggest is centered around having to keep two issues up-to-date vs. a single issue. I am leaning toward including JSD issues into our scrum boards and sprints but need to look deeper into any further downsides.

[Phill Fox]

Many organisations use the Kanban board from JIRA Software to manage requests coming from JSD where they have tight deadlines for responses. This approach allows them to prioritise incidents according to the appropriate conditions and still retain full visibility of the scale of incidents raised.

Organisations which have less tight deadlines do use Scrum boards (note this implies fixes will be in line with the scrum duration and prioritisation). In these instances the incident is added to the backlog alongside all other items and prioritised for resolution alongside the other iterations.  This tends to be with a higher level of change control than the organisations that use a Kanban approach.

I have also seen organisations that retain a fixed capacity in their sprint (eg 10%) to cover the addition of support items during the sprint. However, this does look rather strange on velocity reports as they always appear to over deliver and it is difficult to tell the reality from the statistics.