Best way to use 'versions' across a large backlog made up of lots of Epics

mario.decristofano January 29, 2020

Could I ask for some opinion here please? I've tried to be as specific as possible, am really grateful for any Jira Ninja's to offer expertise - thank you!

The tl;dr is I need to understand how best to use versions for a Jira project, and whether I can automate the tagging of work items into versions using workflow or JQL.

 

I am running a typical digital project made up of approx 80% software delivery and 20% of business, operational, process change & transformation work impacted by the delivery of the software as one fat project. All being managed and tracked in Jira. (well that's the aim). 

So whilst the software delivery teams will be BAU using Jira, and doing all the good Jira stuff as per usual, we have workstream leads (think of them as Product Owners, see below) putting their non-digital tasks also into Jira, and these work items will be mixed with digital items and come together to form service outcomes which form the backbone milestone map of the project.

Example;

I'm building a digital booking service to on-board customers at a front desk in a hotel. There's the more obvious software delivery element of a project like this, but I'm also using Jira to track the building of the desk, in fact the building of the hotel, the surrounding car park and hiring the staff to support the hotel afterwards. Make sense? And I'm wanting to use Jira to track all of this.

So I have a project then made up of many PBI's, which have been logically segregated into tens of Epics which meet the simplest reporting need of segregating the work into chunks which make logical sense. So using the example above we have work items such as like;

  • Build registration form
  • Build post code checker 

and these would inform an Epic called

  • Booking service

But this Epic would also have other work items such as

  • Order a big brown desk
  • Order a chair for the operator to sit on

And we would not want to consider the items to be complete until both the digital part and the non digital part were complete, and of course, manage any inter-dependency between the two.

I envisage then I could use a 'release' to capture from a reporting perspective, work items of either type which may be in different epics, but wont be considered done until the actual outcome has been realised and again, using the example above, the customer is able to walk into a hotel and make a booking at the front desk.

With me?

So I want to create a clear progress reporting structure for up to three potential user archetypes;

  • A release owner to be able to monitor progress of a release
  • A workstream owner to be able to monitor progress of both a release and a workstream
  • A workstream owner to be able to monitor progress of a workstream

The team is made up of 'Workstream' owners - you can think of these as 'Product Owners' if you will. They manage the day to day running of their workstream, doing stand-ups, work item prioritisation and ultimately building out a backlog relating to their workstream which feeds into an Epic

The 'Release owner', well, you can think of this guy as a PMO/Programme/Portfolio level manager and they are interested in the progress of a release, and in this scenario a release is made up of several epics which will contain sprint allocated work items all prioritised and ran by the workstream owner (see above) 

I would like to be able to give a lightweight way of reporting progress against both the Epics, versions and understand the do's and don'ts of not only using versions, but whether the tagging of Epics and items into versions can be automated through the use of workflow and/or JQL

Thank you


M

0 answers

Suggest an answer

Log in or Sign up to answer