Ticket in Active Sprint, on HOLD with missing requirements - ROLLOVER or not?

[Donna Malgieri]

We have a ticket that was put in our active sprint.  A week into the active sprint it was realized the ticket doesn't have the complete approvals so the team cannot work on it.  The tech team wants to close the ticket as "Incomplete" and have a new ticket created in the NEXT sprint, linking back to the closed ticket.   Other option is to let it ROLLOVER.  

What would be your approach this ?

Reminds me that the real mistake was letting a ticket in an active sprint that was not really ready to start work on day one.  

[Trudy Claspill · Accepted solution]

I would recommend AGAINST closing the issue and creating a new issue linked to it. What problem is solved by doing that? The only reason I can think of to do that would be if you have a workflow that prohibits pushing the issue to an earlier status, and you want to actually track the issue from the earliest status again.

Instead I would recommend that you either remove it from the sprint now and put it back in the backlog, or wait until the end of the sprint and then decide to roll it to the next sprint or put it in the backlog.

In either case, the Commitment for the sprint (in the Velocity Chart) will be unchanged as that is set when by what is in the sprint when it is started. And there will be no impact to the Completed metric in the Velocity Chart as that counts only issues that are completed.

It will change your Burndown/up charts though, if you remove it from the sprint before the sprint ends.

[Bill Sheboy]

Hi @Donna Malgieri 

Agreeing with Trudy's suggestion, and perhaps consider this as a topic in the next retrospective to decide how the team can improve to prevent it in the future.

Best regards,

Bill

[Donna Malgieri]

Bill - Yes, it's definitely in our retro - I very much appreciate both of your responding to this ask. 

I think where we failed is that product owners that put tickets into a sprint don't feel any loss if a ticket rolls over, but our tech team does.  This situation actually opened up a healthy conversation - where I was able to explain how the PO as well is negatively impacted by putting a project in as "ready to work" when it really wasn't, only so they could hold the points aside. 

It's all good!   

[Bill Sheboy]

Donna, you could also try "what's in it for you" with product owners: when a team limits WIP and distractions, they have better focus, get stuff done faster/with higher quality, and are able to give their PO more accurate forecasting on value delivery.

__Bill

[Donna Malgieri]

thank you all - this was very helpful