How to handle transparency around carry forward JIRAs?

[Chloe Davies]

We have recently moved to 2-week sprints (previously 4-weeks) and therefore want to develop a transparent set of JIRA metrics that reflect the actual work completed in a sprint vs the plan. 

Our main concern is regarding the treatment of carry forward JIRAs. We have two possible scenarios:

1. Any JIRA put into current sprint but no work has been completed – can be moved out of the current sprint and carried forward to the next sprint directly. No need to clone the JIRA.

2. Any JIRA wherein partial work has been completed – e.g. estimate was 8 days but only 4 days of work has been completed. Reduce the story point on the given JIRA in the current sprint and create a new JIRA for the remaining work.

Our concern is around the transparency of scenario 2 and how this would reflect in the JIRA metrics. We are trying to assess the impact of reducing Story Points on an incomplete JIRA on our metrics i.e how do we record that we committed to do work that we ultimately didn’t do ie. Sprint total should equal = committed work + unplanned work – committed work not completed. Where any difference would then be as a result of a change in capacity.

Any suggestions around this would be greatly appreciated!

[Bill Sheboy]

Hi @Chloe Davies -- Welcome to the Atlassian Community!

I recommend not doing what you described in scenario #2 (i.e. splitting items).  Instead consider just letting the items carry over, and during the team retrospective discuss what was different/special about the work that led to it not finishing, and perhaps what could be done better in the future.

Creating a "normal" process for splitting items that do not finish may incentivize that behavior, and so discourage the team from learning how to improve refinement, planning, and focus during sprint delivery.

Kind regards,
Bill