Hi Rahul, the Sprint Burndown chart will only show the progress of work done within a single Sprint, where as the Release Burndown shows the progress of work for the entire release (also called "Version" in Jira), which may be multiple Sprints.
Hi, Richard! Your videos are very insightful. And, have lots of practical tips. I wanted to give a big shout out to your efforts in this channel! I have a quick question regarding the product backlog grooming session. I want to refer to the example you have given in this video 11:18 So, there is already a 20 pointer in the product backlog. And, the team decides to split it into 5 equal sized items of 4 points. How do you do that with your teams in Jira to avoid this being reflected as additional work? I assume that you are not adding 4 pointers as new items to the product backlog, right? Otherwise, they would be included to the Sprint Burndown chart and Product Backlog as additional work. Ideally, the total size of the Product Backlog should not change after the team breaks down the larger item into smaller items if there is no additional work. Of course, you can create subtasks for the 20 pointer. But, I don't think it would be an ideal solution since they are not subtasks, in real. I would like to know how you get your teams to break down large sized items into smaller items in Jira. Finally, it would be really great to see a detailed video on product backlog grooming session with tips in Jira. Thank you! Ozan
Hi Ozan, firstly apologies on the delay in reply. Great questions. I like to use Jira's splitting feature to break down larger Product Backlog items. You can access the splitting feature by right-clicking on the Product Backlog item and you'll see "Split issue" as an option in the context menu. Unfortunately what Jira will do is then create new Product Backlog items, and yes, that means they are represented as "Work added" on the Release Burndown because they have been added to the release after the release start date. And thanks for your suggestion for a detailed video on Product Backlog grooming. I'll add that one to our Video Backlog :) Thanks! Richard
Hi there, thanks for the suggestion. I've added it to our video backlog. So you don't have to wait the way I handle spikes is by time-boxing them. After the developers have decided and agreed on a time-box for the spike with the Product Owner, they will typically have an idea of the Story Points to allocate. What's important is for the developers to let the Product Owner know if more than the allocated time is required to complete a spike after they have started it's implementation. If more time is required than the developers will need to make sure that the Product Owner is happy to proceed. Hope it helps and let me know if you have any other questions. Thanks! Richard
Hi there! Do you see "Reports" in the left panel? If not you might be using a "Team Managed" project. If that's the case you'll need to click on project settings at the bottom of the left panel, and then click on "Features" and enable reports. That said, keep in mind that the Release Burndown and Version Report are unfortunately not available with Team Managed projects.
Many Thanks Richard ....
Hi Richard, thank you so much for your tips!!
Thanks Randall! it's our pleasure :)
Adjust scope is perfect even I do the same.. Thanks and very useful tips
Thanks Vasanthi! Our pleasure :)
Hi Richard, Can you please let me know what's the difference between the Release Burndown Chart and Sprint Burndown Chart?
Hi Rahul, the Sprint Burndown chart will only show the progress of work done within a single Sprint, where as the Release Burndown shows the progress of work for the entire release (also called "Version" in Jira), which may be multiple Sprints.
Hi, Richard! Your videos are very insightful. And, have lots of practical tips. I wanted to give a big shout out to your efforts in this channel!
I have a quick question regarding the product backlog grooming session. I want to refer to the example you have given in this video 11:18 So, there is already a 20 pointer in the product backlog. And, the team decides to split it into 5 equal sized items of 4 points. How do you do that with your teams in Jira to avoid this being reflected as additional work?
I assume that you are not adding 4 pointers as new items to the product backlog, right? Otherwise, they would be included to the Sprint Burndown chart and Product Backlog as additional work. Ideally, the total size of the Product Backlog should not change after the team breaks down the larger item into smaller items if there is no additional work. Of course, you can create subtasks for the 20 pointer. But, I don't think it would be an ideal solution since they are not subtasks, in real.
I would like to know how you get your teams to break down large sized items into smaller items in Jira. Finally, it would be really great to see a detailed video on product backlog grooming session with tips in Jira.
Thank you!
Ozan
Hi Ozan, firstly apologies on the delay in reply. Great questions. I like to use Jira's splitting feature to break down larger Product Backlog items. You can access the splitting feature by right-clicking on the Product Backlog item and you'll see "Split issue" as an option in the context menu.
Unfortunately what Jira will do is then create new Product Backlog items, and yes, that means they are represented as "Work added" on the Release Burndown because they have been added to the release after the release start date.
And thanks for your suggestion for a detailed video on Product Backlog grooming. I'll add that one to our Video Backlog :)
Thanks!
Richard
Can you make any video on ' how to handle spikes', do we need to estimate? where we need to track down the solutions for spikes??
Hi there, thanks for the suggestion. I've added it to our video backlog. So you don't have to wait the way I handle spikes is by time-boxing them. After the developers have decided and agreed on a time-box for the spike with the Product Owner, they will typically have an idea of the Story Points to allocate.
What's important is for the developers to let the Product Owner know if more than the allocated time is required to complete a spike after they have started it's implementation. If more time is required than the developers will need to make sure that the Product Owner is happy to proceed.
Hope it helps and let me know if you have any other questions.
Thanks!
Richard
Hi Richard, i can't see forecast and management reports , how can i enable ? pls reply Richard
Hi there! Do you see "Reports" in the left panel? If not you might be using a "Team Managed" project. If that's the case you'll need to click on project settings at the bottom of the left panel, and then click on "Features" and enable reports. That said, keep in mind that the Release Burndown and Version Report are unfortunately not available with Team Managed projects.