I'd like to know how it' possible to consider new sub-tasks as an additional and unexpected workload after a sprint is started?
According the Scrum and the Lean principles, the team isn't supposed to work on anything outside the sprint simply to avoid a waste of time is a US isn't elected.
Hense, the team start to work on a US only when the sprint really start. they split up the US into sub-tasks that can be done by different member of the team.
Saying that, why this strange Jira's behavior regarding the sub-tasks ?
The only issue is that the burndown chart is useless !
I assume that you are capturing some estimate against each sub-task and that this is then being included in your burndown charts which is why you are considering them to be broken.
JIRA Software considers all estimates set at the start of the sprint as the committed delivery. Any adjustment to items in the sprint - changes to estimates, additional tasks, etc as a change in scope.
The solution is to either not add estimates to sub-tasks (as their estimate is already included in the estimate for the US.) or you could have the sub-tasks be created as part of your sprint planning to ensure that estimates are included in the scope committed at the start of the sprint.
Hey admins! I’m Dave, Principal Product Manager here at Atlassian working on our cloud platform and security products. Cloud security is a moving target. As you adopt more products, employees consta...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs