Thanks for this great video. I have a question :) What if we take our start point as the sprint planning for all the items ? If an item is of high importance (included in sprint goal) and we cannot start this immediately, this is a risk for us. As we have a time box and sprint goal, I believe we should not only include items that are active. What do you think ? Waiting stage is where most of your unpredictability lies and we should see this info in aging and daily scrums, thank you !
Hi and thank you, I really appreciate that. Ok, the point about the ageing chart is to help ensure that you don’t break your forecast for single work items. If your single work item forecast at the 85th percentile is 6 days then you want to know when it’s getting close to that so you can do something about it. This is based on cycle time (the point at which you start work on a work item to the point at which it’s done). Cycle time will include inactive time if work has already started and so it will show on your ageing chart. So if you start work on a work item but then it goes into blocked all of that time will still show. The only time it won’t show is if you haven’t started work on the work item at all. Just because it’s in the sprint doesn’t mean work has started. It’s only started when a developer picks up that work item and starts work. I usually have a to do column where all work items live when taken into sprint. But this is a queue. They only start their cycle time when it moves from to do to in progress. Remember though the important thing is the sprint goal, just because you take 20 work items into sprint don’t necessarily mean all 20 need to be done to achieve the sprint goal. Maybe 15, maybe 23 (because you forgot a few). Hope that makes sense and helps a little.
Thank you so much for effort in spreading agile knowledge. This is very helpful. I have a query, reg, ageing WIP chart For instance - My sprint is 2-week cadence. Historical cycle time is 8 days Age of story is 2 days its in WIP - which is normal. But, if we are in 6 th day of sprint. There are more probability that this story will spill. How should I address / identify this? Thanks!
Hi and thank you that means a lot to me 🙏👍 Ok great question, on the ageing chart you need to mark your percentiles, 50%, 70% and 85% (this is what I usually use). At your Daily Scrum, if you see a story at the 50th percentile then you may need to take action depending on what status it’s in. For example, if it’s ‘in test’ then it’s probably fine but if it’s in ‘blocked’ you will need to do something. If a story is close to the 70th percentile then have a conversation on it. So review the ageing chart with the team every day at the Daily Scrum. For it to work each team member must ensure that their stories are in the correct status every day. Hope that helps.
For a team handling numerous tasks due to client requests and bugs, there will be a substantial number of tickets that need to be created and worked on. Inputting these tasks or issues could potentially be a stressful and challenging process, especially when managing an Excel sheet. Is there a more efficient way to automate this process, perhaps by using Jira or a recommended plugin like "Time in Status" which can be found on jira apps? Additionally, there's a concern about managing capacity planning, given the influx of requests and the need to prioritize higher-priority tickets. Consequently, some tickets might linger in the active column for an extended period, leading to them aging and potentially falling below the desired 85% percentile. What's the best approach to address this issue and ensure smoother workflow management?
Hi, my videos are designed to introduce the concept and provide a free way of accomplishing it to show users what’s possible. They aren’t really for long term organisational use. So the answer to your question is yes but not for free. Actionableagile is available from the Atlassisn Marketplace for Jira (it’s also available for Azure DevOps) and I think there is another called Work Item Essentials as well, as is usual with Atlassian the plug ins are priced on a Jira per seat basis. Or there are other tools out there like Kanbanize that has all these features built in.
Hi, you’ve completely misunderstood. We do not track the age of anything in the backlog, that would be pointless. We track the age of work that is active, that we are doing now.
Great video, great content! One question though: if you have an estimation for a stakeholder and you're not getting there - simply splitting a story that is taking too long is not going to help getting to the goal of delivering the value needed... Or am I missing something?
Hi and thank you, I really appreciate that. Well the most important thing in the sprint is to achieve the sprint goal (the assumption here is that the sprint goal does actually add value). If a story is taking too long and if by splitting it you can do the part that adds value to the sprint goal then that would be a good strategy. But if that story that’s taking too long doesn’t add much value to the sprint goal then consider not doing it at all. It’s perfectly fine not to complete everything in the sprint backlog as long as the sprint goal is achieved.
@@TheAgileLeanGardener Yes, whether you use Scrum or not it's about delivering value rather than getting a fixed amount of stories delivered. Thank you for clearing that out since for me at least it sounds a bit weird as a rule of thumb.
Hi, no problem, let me know if I can help and I’ll do my best. Yes people often focus on getting everything done in the sprint backlog and forget that the objective is the sprint goal. It gets even worse in teams where there is no sprint goal.
@@TheAgileLeanGardener Yes, if you can deliver 95 % of the value by splitting instead of less than 95 % because of the delay it might be well worth it.
Thanks putting this together. I am looking at your aging chart. I have calculated my cycle times for my team over the last 8 months. I know my cycle time for the 85% is greater than the length of my sprint; however, I am trying to understand the percentiles in the chart. Are you stating that if an item reaches the # of days associated to the 50% of my cycle time it is greater than 50% of the tickets I have completed in my past and therefore the likelihood it will complete before the end of the sprint decreases?
Hi and thanks 🙏👍 yes, the older a story gets the greater the chance it will not complete to the 85th percentile. It can be a bit tricky to get your head around it but each time a story halves the amount of time left to the 85th percentile it doubles the chance of it not completing to the 85th percentile. I wouldn’t worry too much about that though. The key takeaway is that even at the 50th percentile you should take a good look at the story - if it’s already in test then it’s probably fine but if it still in progress or blocked then it’s most likely in trouble and you should take action. The key thing is to understand how old all the stories are and where they are in your workflow to make a decision if action is needed. The thing I didn’t mention in the video is how important that particular story is, not all stories carry the same importance. If you’re doing Scrum you should also consider its importance to the Sprint Goal. Hope that helps.
Great video, thanks! If I'm using KFM (Kanban Flow Metrics) with scrum, how can I track progress of the team in a s sprint in Jira - what chart(s) in Jira can I use? Thanks
Personally I would concentrate on the sprint goal (assuming you have a product goal). Jira doesn’t have any decent charts, I wouldn’t bother with them. This is why I created the ageing wip Excel and the Monte Carlo Excel, using these you can do it for free. The trick is getting the data out of Jira - you can do this for free for cycle time/throughput by following my recent ‘extract data from Jira’ video but to get the data for the ageing wip chart you’ll need a plugin like Time in Status (you can also do it with Jira automation but it’s a little trickier). Or you could just spend the money and buy the ActionableAgile plugin that gives you everything.
Thanks! Looks like this approach is needed to help you prove the forecast 🙂
Yes absolutely, to help ensure the forecast remains accurate but also to help improve on the forecast .
I have never heard of this chart! But I will give it a try! Thank you for sharing great content!!
Yes give it a go and let me know how you got on 👍
Thanks for the template, really appreciate that, will check it out
You're welcome, let me know how it goes!
Great video to actively monitor the process proactively!
Thank you glad you liked it :-)
Very interesting thx!
Thank you :-)
Genial
Gracias! :-)
Thanks for this great video. I have a question :) What if we take our start point as the sprint planning for all the items ? If an item is of high importance (included in sprint goal) and we cannot start this immediately, this is a risk for us. As we have a time box and sprint goal, I believe we should not only include items that are active. What do you think ? Waiting stage is where most of your unpredictability lies and we should see this info in aging and daily scrums, thank you !
Hi and thank you, I really appreciate that. Ok, the point about the ageing chart is to help ensure that you don’t break your forecast for single work items. If your single work item forecast at the 85th percentile is 6 days then you want to know when it’s getting close to that so you can do something about it. This is based on cycle time (the point at which you start work on a work item to the point at which it’s done). Cycle time will include inactive time if work has already started and so it will show on your ageing chart. So if you start work on a work item but then it goes into blocked all of that time will still show. The only time it won’t show is if you haven’t started work on the work item at all. Just because it’s in the sprint doesn’t mean work has started. It’s only started when a developer picks up that work item and starts work. I usually have a to do column where all work items live when taken into sprint. But this is a queue. They only start their cycle time when it moves from to do to in progress. Remember though the important thing is the sprint goal, just because you take 20 work items into sprint don’t necessarily mean all 20 need to be done to achieve the sprint goal. Maybe 15, maybe 23 (because you forgot a few). Hope that makes sense and helps a little.
Thank you so much for effort in spreading agile knowledge. This is very helpful.
I have a query, reg, ageing WIP chart
For instance -
My sprint is 2-week cadence.
Historical cycle time is 8 days
Age of story is 2 days its in WIP - which is normal.
But, if we are in 6 th day of sprint. There are more probability that this story will spill.
How should I address / identify this?
Thanks!
Hi and thank you that means a lot to me 🙏👍 Ok great question, on the ageing chart you need to mark your percentiles, 50%, 70% and 85% (this is what I usually use). At your Daily Scrum, if you see a story at the 50th percentile then you may need to take action depending on what status it’s in. For example, if it’s ‘in test’ then it’s probably fine but if it’s in ‘blocked’ you will need to do something. If a story is close to the 70th percentile then have a conversation on it. So review the ageing chart with the team every day at the Daily Scrum. For it to work each team member must ensure that their stories are in the correct status every day. Hope that helps.
For a team handling numerous tasks due to client requests and bugs, there will be a substantial number of tickets that need to be created and worked on. Inputting these tasks or issues could potentially be a stressful and challenging process, especially when managing an Excel sheet. Is there a more efficient way to automate this process, perhaps by using Jira or a recommended plugin like "Time in Status" which can be found on jira apps?
Additionally, there's a concern about managing capacity planning, given the influx of requests and the need to prioritize higher-priority tickets. Consequently, some tickets might linger in the active column for an extended period, leading to them aging and potentially falling below the desired 85% percentile. What's the best approach to address this issue and ensure smoother workflow management?
Hi, my videos are designed to introduce the concept and provide a free way of accomplishing it to show users what’s possible. They aren’t really for long term organisational use. So the answer to your question is yes but not for free. Actionableagile is available from the Atlassisn Marketplace for Jira (it’s also available for Azure DevOps) and I think there is another called Work Item Essentials as well, as is usual with Atlassian the plug ins are priced on a Jira per seat basis. Or there are other tools out there like Kanbanize that has all these features built in.
Name it what it really is "A Wish List". If a story is in the backlog to age, then it is not needed: remote it.
Hi, you’ve completely misunderstood. We do not track the age of anything in the backlog, that would be pointless. We track the age of work that is active, that we are doing now.
Great video, great content! One question though: if you have an estimation for a stakeholder and you're not getting there - simply splitting a story that is taking too long is not going to help getting to the goal of delivering the value needed... Or am I missing something?
Hi and thank you, I really appreciate that. Well the most important thing in the sprint is to achieve the sprint goal (the assumption here is that the sprint goal does actually add value). If a story is taking too long and if by splitting it you can do the part that adds value to the sprint goal then that would be a good strategy. But if that story that’s taking too long doesn’t add much value to the sprint goal then consider not doing it at all. It’s perfectly fine not to complete everything in the sprint backlog as long as the sprint goal is achieved.
@@TheAgileLeanGardener Yes, whether you use Scrum or not it's about delivering value rather than getting a fixed amount of stories delivered. Thank you for clearing that out since for me at least it sounds a bit weird as a rule of thumb.
Hi, no problem, let me know if I can help and I’ll do my best. Yes people often focus on getting everything done in the sprint backlog and forget that the objective is the sprint goal. It gets even worse in teams where there is no sprint goal.
@@TheAgileLeanGardener Yes, if you can deliver 95 % of the value by splitting instead of less than 95 % because of the delay it might be well worth it.
👍
Thanks putting this together. I am looking at your aging chart. I have calculated my cycle times for my team over the last 8 months. I know my cycle time for the 85% is greater than the length of my sprint; however, I am trying to understand the percentiles in the chart. Are you stating that if an item reaches the # of days associated to the 50% of my cycle time it is greater than 50% of the tickets I have completed in my past and therefore the likelihood it will complete before the end of the sprint decreases?
Hi and thanks 🙏👍 yes, the older a story gets the greater the chance it will not complete to the 85th percentile. It can be a bit tricky to get your head around it but each time a story halves the amount of time left to the 85th percentile it doubles the chance of it not completing to the 85th percentile. I wouldn’t worry too much about that though. The key takeaway is that even at the 50th percentile you should take a good look at the story - if it’s already in test then it’s probably fine but if it still in progress or blocked then it’s most likely in trouble and you should take action. The key thing is to understand how old all the stories are and where they are in your workflow to make a decision if action is needed. The thing I didn’t mention in the video is how important that particular story is, not all stories carry the same importance. If you’re doing Scrum you should also consider its importance to the Sprint Goal. Hope that helps.
Great video, thanks! If I'm using KFM (Kanban Flow Metrics) with scrum, how can I track progress of the team in a s sprint in Jira - what chart(s) in Jira can I use? Thanks
Personally I would concentrate on the sprint goal (assuming you have a product goal). Jira doesn’t have any decent charts, I wouldn’t bother with them. This is why I created the ageing wip Excel and the Monte Carlo Excel, using these you can do it for free. The trick is getting the data out of Jira - you can do this for free for cycle time/throughput by following my recent ‘extract data from Jira’ video but to get the data for the ageing wip chart you’ll need a plugin like Time in Status (you can also do it with Jira automation but it’s a little trickier). Or you could just spend the money and buy the ActionableAgile plugin that gives you everything.
@@TheAgileLeanGardener Fantastic, thanks
Are you using Jira in the video?
Hi, yes I’m using Jira in the video but it applies no matter which agile tool you’re using.
Do you use jira at work too?
Yes, it’s very common in the UK. It’s not the best but then they all have their flaws.