It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Use of multiple sprints for a single release-level reporting

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?

 

1 answer

0 votes

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

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.

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Agile

Where is my version 1.23 deployed? or How to manage multiple versions across multiple environments?

Introduction In this article we describe the complexity of managing release cycles of complex IT solutions that comprise of a number of Apps, Service and/or Microservices. In particular, we will tou...

488 views 0 3
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you