Any way to setup a desired Epic velocity for a sprint?

Question

Among several business initiative epics, we've got an Epic that corresponds to Code Quality tasks. As it's unsustainable to fully focus on that Epic for a duration of time, as well as being never-ending, it'd be nice to setup some sort of default guideline when planning a sprint.

Say, when planning a sprint, there should be a warning if there aren't at least X nr of tasks or story points from that particular epic should be included in the sprint. Is there a way to accomplish that?

Bill Sheboy · Answer

In my experience, when refactoring and other "code smells" are addressed as part of daily working methods there is no need for separate work items to manage (or defer) such things.  And it reduces "spirited conversations" of assigning story points to such types of work items.

Any ways...

You describe a flow to "get a warning during planning if there are too few Code Quality tasks".  There is nothing built-into Jira that would support that.  Perhaps there is a marketplace addon for this.

For a possible, noisy, work-around, you could try card colors and automation rules:

* Sprint planning, using Jira, typically occurs while viewing the Backlog view.  There needs to be some event to trigger the limit check, and so that could be adding / removing an item from the sprint.
* What if there was an indicator on every issue in the sprint to indicate a capacity issue: a custom field, a label, etc.?
* An automation rule could be triggered on add / remove an issue for the sprint during planning, to add / remove the indicator, based on approaching the limit.  Assumption: your "improvement" issues already can be detected using issue fields.
* Adjust the card colors to check the indicator (e.g. red for below limit)
* So the flow is:* new sprint is empty
* add an issue
* rule triggers, sees below limit, and indicator is added
* backlog view updates to show card color red
* repeat until up to limit
* sprint starts
* trigger a new rule, which removes the indicator from all sprint issues

Vilhelm Lundqvist · Answer

It's not necessarily a short term need.

The Code Quality Epic includes a bunch off short-term need stuff like improvements to CI processes, which can be picked up and discussed as you mentioned.

But as code gets added, packages get updated, etc, needs for addressing these and performing refactors will arise as time goes on, hence the term never-ending.

I'm not necessarily looking for a warning popup when a sprint is started - moreso when creating and allocating tasks to a sprint! It can be addicting to only add feature tasks and stories to a sprint, but to maintain code health it'd be nice to get a warning during planning if there are too few Code Quality tasks.

Bill Sheboy · Answer

Hi @Vilhelm Lundqvist -- Welcome to the Atlassian Community!

To me, this sounds like a short-term need (hopefully!) and something to handle during backlog refinement and confirmed during sprint planning...before the sprint starts.

If the team waits until after the sprint starts and then runs a check/report on missing work item types (i.e., code quality) it will appear as a scope change for the sprint.

What do you think of this approach:

* discuss this with the product owner to confirm they understand the need
* add a quick filter to show items of this type using JQL (e.g., parent = yourCodeQualityEpicKey )
* during sprint planning, filter the backlog with that quick filter
* confirm if the capacity matches the team's expectations, and make adjustments
* after the sprint in the retrospective, assess how selecting items helped code quality

Kind regards,
Bill