Hi @Jenny Luther
What problem are you trying to solve by doing those things? That is, "why do that"? Knowing that may help the community to offer some alternatives.
Until we know that...
I believe both of those actions are possible, and I respectfully recommend not doing either one of them with automation rules when there is a scrum team involved with delivering the sprint plan.
When a scrum team is working on the items in the sprint plan, it is possible for progress to be "blocked" for a variety of reasons. This can be an opportunity for the team to swarm, learn, and decide how to clear the blocker / impediment faster. If instead the blocker lingers, the team may start other work, driving up WIP, and so not be ready to re-start when the blocker eventually clears...leading to re-prioritization, potential errors, rework, and longer completion times.
When something truly cannot be completed during the sprint, a quick conversation with the team and Product Owner may lead to a sprint scope change. And, provide another opportunity for the team to learn: "what could we have seen to prevent this blocker before sprint planning". Changing sprint scope with an automation rule will make this symptom less visible to the team.
Regarding automatically moving an item to "In Progress" based on a date, teams normally pull items into work based on their capacity: when ready, pull an item into work. And so automatically moving items through the workflow may give stakeholders and leaders the impression work has started, even when no one is actively looking at it. Perhaps it will then be marked as "blocked", feeding into the first scenario.
Please consider discussing these scenarios with your team and team coach to decide how they might be addressed better.
Kind regards,
Bill
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.