Normally, you have a sprint of tasks that you expect to be fully completed. However, in my case, we have four functional teams , each working on their own subtask of a parent task. Since each task requires different amount of work from a team and every team has different productivity, I have to put enough tasks in a sprint for a team, even though I know other teams would never possibly reach the end of task list.
Therefore, we have split all our tasks into three classes, in the context of a particular sprint.
Must Have: all teams think they will finish the subtask of it before the end of the sprint.
Nice To Have: all teams think they could at least possibly finish the subtask of it, that is, some think they will, some not sure. So technically, it's acceptable that none of the Nice to Have tasks are done.
Won't Have: at least one team thinks it could never complete the subtask of the task
Now, ideally, in a burndown chart, I would expect my "remaining work" line following the guideline. However, in my case, this would never happen, because I know we have too much work in a sprint, but they have to be there so that everyone has work to do.
So I'm wondering if there's a way to change the filter of sprint reports, like, I would only want to the see burndown chart of "Must Have" tasks. But if there's a better way to manage my sprint, I'd be much glad to hear about it : )
I think, you should only plan stories and tasks in your sprint that are likely to be done at the end of the sprint.
The burndown chart reflects all the storypoints from your sprint, it can't be filtered. If you plan unrealistic story points in your sprint, the burndown chart is also quite useless.
I would create a board for each team. Put their stories and tasks into their sprint, so your planning is correct and the burndown also.
Thanks for your answer! It's a pity I can't change the filter to some extent.
I understand your intention of having four boards and four sprints. But generally, I wanna encourage cross-functional behavior, so I'd still want everything on the same place and to be available for everyone on their daily working basis. Also, it's important for our team members to work on part of a feature rather than isolated sub-tasks.
So, here's another workaround I have just figured out. I will have two concurrent sprints in Jira. The first one is for "Must Have" issues, and the second one for "Nice to Have" and "Won't Have" issues. Teams that have finished the subtasks from the first sprint should continue to the second. I will then have two burndown charts, and the way I monitor these two charts is to make sure the "current progress" line is in between the two guidelines.
Note: The "Must Have" sprint is an under-commited sprint
What do you think?
I'm looking forward to your reply!
I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...
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