Apply a Sprint if the status changes to "In Progress"

[stmiller]

Scenario:

A new team consistently keeps forgetting to add the Sprint to their work, but they do remember to change the "In Progress" field.

I explored some automation options, trying to see if we could setup a workflow that if an Issue changes from "To Do" to "In Progress" the current (Active) Sprint field is populated.

I'm told that the "Sprint" field isn't directly editable using "Sprint" in JSON. So I would have to "hard code" each Sprint ID. This would mean I have to manually change the Sprint ID, each Sprint.

Anyone have a better idea on how do this, but not hard code it?

Stephanie

[John Funk · Accepted solution]

Hi @stmiller 

You should add a transition screen with the Sprint field to the transition to In Progress. Then add a validator to make the Sprint field required. Make them do what they are supposed to do.  :-)

[stmiller]

• Now this i love! Thank you @John Funk
• I'm not above making them do it, but it also solves some other challenges for me too.
• And I just can't chase them around saying "do this do this" as I'm not the supervisor or empowered manager.
• Thanks again for a great idea." 

[John Funk]

You are very welcome!

[stmiller]

I appreciate no lectures, and the help. Happy Friday Eve!

[Bill Sheboy]

Hi @stmiller 

Yes, and...to John's suggestions:

When a team regularly starts unplanned work items after the sprint begins, that is a symptom of some root cause problem.  That could include:

• work items are not refined enough to be built, leading to pulling more work that is ready
• the sprint plan is not aligned to team capacity, etc.
• team does not focus on the planned goal and sprint backlog
• product owner / champion (or others) disrupt the team's planned work
• team has production support responsibilities not accounted for in the sprint plan
• etc.

I recommend using the next team retrospective to discuss this symptom, identify the root cause, and decide how to experiment to improve and correct / mitigate the cause.  Otherwise, automating the "fix" to set the sprint field in the work items will both conceal the cause and make it a normal practice to ignore the sprint plan and goal.

Kind regards,
Bill

[stmiller]

I am aware. However, this is not a software development team.

They are an Application Support team with different directives, and they are not empowered to function like a development team.

Nor am I empowered to be their Scrum Master. I am simply their technical resource which is shared with the PMO.

Be well.