Block tickets from getting added to active sprint when Original time estimate is Blank

[srikanth_rao]

Hello Team,

I have a requirement where I need to block tickets from being added to the active sprint when the Original Estimate field is blank or has a value of 0 hours.

I realize I can make the field mandatory, but we have people from the sales team or support team creating tickets, and it will be difficult for them to provide an estimate.

Any help on a possible solution to the above request would be much appreciated.

Please let me know if you need any further details.

Thank you!

[Stephen_Lugton]

Hi @srikanth_rao 

As long as you add tickets to your sprint from a board rather than editing the sprint value on the ticket you can:

Set up a quick filter on the board

e.g. 'Hide un-estimated tickets'

originalEstimate IS NOT EMPTY

When that filter is selected you won't see any un-estimated tickets on the backlog

In case you forget to turn that quick filter on you can also add a card colour query so you can see any un-estimated tickets easily:

🟥 originalEstimate IS EMPTY

[Thorsten Letschert _Decadis AG_]

I like the quick filter approach, a good intermediate solution between blocking upfront and automatically (or unattended) removing issues. It draws attention to those issues and leaves it up to the user to decide whether to add the estimate or remove the issue from the sprint.

[Stephen_Lugton]

Yes, you can also create a second quick filter to only show un-estimated tickets ('originalEstimate IS EMPTY') which can help show what needs to go through a refinement session

[Thorsten Letschert _Decadis AG_]

HI @srikanth_rao ,

AFAIK there is no easy answer to your question (yet). A corresponding feature request is being tracked here: https://jira.atlassian.com/browse/JSWCLOUD-15376

However, depending on your setup, you might want to give the following workaround a try:

• You've stated that making estimated required globally doesn't fit your needs since ticket creation should still be possible without providing an estimation.
• You could still incorporate an additional status, e.g., "Ready for Sprint", add a validator to the transition between "New" and "Ready for Sprint" that ensures that all required fields, e.g., "Original Estimate," are se,t and ensure that the backlog only shows the issues "Ready for Sprint."
• This ensures that your sales and support team can still create issues without estimation, but only issues with an estimation set can be added to a sprint via board.

While this is a proactive workaround, a reactive one might incorporate an automation rule that removes issues from an active sprint if no estimation is provided. However, I prefer preventing inconsistent states upfront to the subsequent cleanup by automation rules.

Regards from Germany,
Thorsten