0

Ok, a little background. So the company I work for has SIGNIFICANTLY hamstrung the use of Jira. They have eliminated the enhancement and feature issue types among many others to the point where we only have epics, stories, bugs, and subtask issue types available to us.

Problem: we have a new "nextgen" system being worked on and there are about five scrum teams working on it separately. Each team has their own series of epics for their work, so one single epic can not be created and used for this purpose. Because they have removed the feature issue type from use (which would have been useful here since epics roll up to features), they can not get a burndown based on the work they are collectively doing separated by team so instead they have all created their own fix/version release and are using the release burndown to track their work instead.

As the release manager, it is my duty to track, record, maintain, and otherwise ensure that our release procedures and other assorted quality control methods are sorted out so we don't get compromised in an audit situation. What this has done is now I have tickets appearing in multiple release fix/versions where there has (or will have) only one deployment. Policy currently states that any jira ticket that is in multiple fix/versions means that that particular jira ticket has been deployed twice. Now, if we were to be audited, it would obviously get rather confusing to prove when and where a ticket was ACTUALLY deployed.

There has to be another way to track multi-team, multi-epic burndowns. Please someone help me.

2
  • Am I reading this correctly that each team has their own Fix Version? Also, are you using Classic or Next Gen jira projects?
    – Thomas Owens
    Sep 9 '20 at 20:53
  • Each team has their own fix/version and we are using classic.
    – Suvikielo
    Sep 9 '20 at 21:21
1

I would do the following:

  1. Make sure you are using one Jira project. One project in Jira equates to one product. You can also manage your cross-team workflows, issue types, and other settings more easily.
  2. Add a custom field to all of the issue types and call this field "Team" or "Scrum Team" or something similar. Set this up so that way an issue allocated to a team will have this field set on it.
  3. Create boards, keyed off of this new team field. Each team should have its own board. Depending on your workflows and situation, you may also want to create a board for issues without a team (so they are more visible) and, depending on your workflow, epics to give visibility into their status to management. This will enable each team to start tracking their own Kanban and Scrum metrics, since those are keyed off of boards.
  4. Use things that exist across teams, like releases, to track across teams. Your release tracking tools will actually work now, since your teams are tracking their own work on their boards and all work allocated to a release has the same Fix Version applied.
  5. Make effective use of labels and components to help build queries for reporting.
  6. If you need data, measurements, and metrics, look for plugins. If you don't want or can't get plugins, you can always abuse boards. I've had luck with things like Kanban boards for Epic status or creating a "Release" Scrum board where each "Sprint" is started with the first Sprint working toward the release and the "Sprint" is ended with the release to generate the Sprint-related metrics. There are some interesting ways to (ab)use boards for visualization and metrics.
10
  • These all sound like good ideas, but they have already been implemented. Each team has their own board and we are all in the same project (both our legacy and nextgen work is in the same project in jira. They are specifically using the burndown charts to track time until release to make sure they are on track.
    – Suvikielo
    Sep 9 '20 at 21:41
  • @Suvikielo So...what's the problem? If you're doing this, you should have everything you need.
    – Thomas Owens
    Sep 9 '20 at 21:45
  • the problem is that my teams are still using the fix/version and not using their boards. using the boards is the solution to not using fix/version for burndowns?
    – Suvikielo
    Sep 9 '20 at 21:52
  • I'd have to log into a Jira instance, but by using boards, you can definitely get per-team Sprint burndowns. If you want a per-team release burndown, you may have to resort to something of a hack - create two boards per team and use one to track toward a release and another to track Sprints. I don't think you can filter a release burndown for each team, but I don't know why you'd want to. I think there's something else going on and that's an X-Y problem.
    – Thomas Owens
    Sep 9 '20 at 21:59
  • i think part of the problem is that theyre only using scrum boards. i dont think its crossed their minds to use a kanban style board to track cross-sprint work.
    – Suvikielo
    Sep 9 '20 at 22:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.