Use of multiple sprints for a single release-level reporting

[Yash Doshi]

hi all - I have a rather peculiar deployment of Jira cloud that I am currently doing for a client. The teams are working in 2-week sprints, however, the senior stakeholder reporting requirements seem more traditional. Trying to find a way to balance both, but haven't yet found a way. I appreciate the help in advance.

Case: I have a Program running in Jira which has 10 different Jira Projects equivalent to 10 different products. Now, each of these products has 1 or more sub-products, which can either be release together individually or as a group. 

Let's call one of the products as Product X, which has sub-products X1, X2, X3. We have a Jira Project created for Product X. Ideally, within this project, teams working on X1, X2, X3 are different scrum teams. X1, X2, X3 have different release schedules and start dates i.e I may have already completed 3 sprints (out of 6) for X1 when X2 starts their work. 

Usually, I would want to report on separate releases on these separate products. However, the reporting requirement from senior stakeholders is at a Product X level i.e they want X1, X2, X3 sub-products to show progress in 1 release burndown. Potentially, all my sub-products could have separate sprints. However, reporting them into 1 release makes me think that the Release burndown forecast may be interpreted incorrectly. For eg: If I say Product X has completed 100 story points in total, that may be viewed as the stakeholders as good progress. Whereas, in reality, I may have completed 90 story points for X1, and 5 each for X2 and X3.

The initial thoughts are to leverage the system Jira reporting as much as possible. Is there a better way to tackle this problem or am I missing something obvious?

[Ste Wright]

Hi @Yash Doshi

I don't think you're missing something here - although I do think you're best to provide description with your metrics.

For example, you could have:

• A burn-up per release / team for each sprint
• A CFD per release / team for each sprint
• An overall burn-up and CFD

^ With these you can show the Program Manager how each team, release or sub-product is progressing, explaining each team's velocity and movement towards production.

The overall burn-up and CFD can then show these together.

Helping visualise both shows that whilst we're "doing" lots - we might not be releasing a lot. I think this will help change their perception of what "completed" looks like. I use burn-ups also as these show scope change, not just completion rates.

I'd also consider how much dependencies play into this - if you're becoming blocked in X2 because X1 is delayed, you're best to show this.

Ste

[Yash Doshi]

Thank you Stephen for the very useful input. I have already set them up in Jira to report on "so-called" major and minor releases. The major release will be at a Product X level. The minor release will be at an X1, X2, X3 level. 

The overhead with this approach is that multiple fix versions need to be tagged against an issue which I think is acceptable based on the demands.