6

What happens in Scrum when the development team is the support team as well? How can this be improved using Jira?

We can't have a fire fighter because not all developers can solve both front-end and back-end issues. But the support issues make team velocity difficult to obtain.

Ursula
  • 233
  • 4
  • 13
  • 1
    This may sound harsh, but causing fewer issues in the first place is a great way to help stabilize your teams ability to deliver new features and reduce the constant firefighting. – jessehouwing May 17 '16 at 18:06
  • One thing you may wish to consider that would help your team - other than Barnaby's excellent answer below - is to look at how your team can cross-skill each other to a point where you no longer have single-point dependencies on "this is a back end issue" vs. "this is a front end issue". At the end of the day, you have an issue, and the team should be able to resolve it with the skills they have collectively. Let the team drive how they can do that in the most efficient way possible; one way would be looking at dedicating time to learning skills from each other or actively pairing on issues. – f1dave Jun 01 '16 at 03:41
  • I'm voting to close this question as off-topic because it is not related to programming. – Ajay Brahmakshatriya Nov 03 '17 at 06:46

4 Answers4

8

Mike Cohn wrote a good article on sprint planning for teams with a lot of interruptions.

He suggests having a rolling estimate of the average time spent on interruptions. Then allow for that when you do sprint planning.

For example, say the team averages 30% of their time spent on fixing issues. When you do the planning you plan for a capacity of 70% for development work.

As you mention in your question, nominating a person to handle issue fixes is a common approach. This is beneficial as it allows the other members of the team to focus on new development work without unexpected interruptions. In your situation where developers are specialists this is more difficult to achieve. You may want to consider doing some cross-skilling so that developers can handle a broader range of issues. They may not fix some issues as well as a specialist, but the loss in efficiency is gained back by the rest of the team avoiding interruptions.

Other things worth considering:

  • Triage bugs and only do the critical ones immediately. Schedule the other bug fixes as a part of your next sprint planning session. This may be easier to achieve if you have short sprints (say 1 week long) as the users will have less time to wait for a fix.
  • Analyse the bugs and see if some development work could potentially prevent future issues. For example, you may find that a lot of bugs occur due to bad data. Spending time making the code more tolerant to bad data can help.
  • Consider investing more time in automating your regression tests. This up-front investment of time can reduce the number of future bugs. It may seem like a lot of time and effort to do this, but making your workload more predictable can be valuable enough to offset this cost.

Production bugs have a bigger impact than the time spent fixing them due to the unpredictable way in which the work arises. That is why focusing on quality makes sense, even if it does seem like a lot of extra effort.

Barnaby Golden
  • 4,176
  • 1
  • 23
  • 28
1

So the SCRUM is really for planned work, and if there is a lot of interruptions it may not be the best approach, maybe you should look at kanban or combination of both?

Dariusz Bielak
  • 415
  • 2
  • 7
1

@Banarby Golden's answer very much answers the core question already, but since you've also asked about how to implement this in your JIRA project management:

I'd suggest using different projects or different epics for development and support tasks. Using a default Scrum project for development and a dedicated Kanban project for support issues seem's like a reasonable aproach to me (we are using this technique as well).

You can also create boards which span multiple projects, if you want to visualize the whole workload.

Kevin Wittek
  • 1,369
  • 9
  • 26
1

You could adapt the process based on the type of work coming in to sprints. It doesn't have to be set in stone as things can change over time.

  • Kanban gives teams just enough work so that they are consistently working at capacity.
  • Scrum divides work into sprints (fix-length iterations) allowing teams to work on top priority stories.
  • Scrumban is a hybrid of Kanban and Scrum. It's based on having a continuous flow of work and follows a pull-system. Stories exist in a backlog and teams still operate in sprints but WIP (Work in progress) is limited through each stage of the workflow and productivity measurements are in place using Cycle and Lead time metrics.

Note: Cycle time is the time a story takes from start to finish in the teams workflow. Lead Time is the total time the story appears on the Scrumban board.

Clarice Bouwer
  • 3,631
  • 3
  • 32
  • 55