This is great! I recently forced a change in our approach and now we strictly recognize done items and nothing else for velocity. It worked immediately to increase the amount of tasks completed to an all time high!
Thank you for the valuable insights. I have allowed few sprints for partial credit for partial completed story. Later I realized that this behaviour may lead to invalid velocity and this impacts the predictability of prod increment. I find a gap and started coaching teams to split the user stories which can be completed in shorter duration to get faster feedback in less than a day or a day during Sprint Planning and Backlog refinements.
No credit for you! Been doing that from the beginning. When I get pushback, I ask, "If you took your car in for service, and it was only 85% complete, would you pay for it?" I also make sure not to beat the team up for an occasional miss. It happens. And if I see a trend, we focus on what's getting in the team's way, not "why is Joe always late with his stories." I have needed to talk to individuals occasionally, but it's rare.
Great. I'm glad to hear our approaches are similar. I think missing occasionally is a good sign of a team trying hard rather than playing it safe, feeling they always need to do everything.
I agree 100%. In my experience this is also a red flag when assessing an organization's agile maturity. Giving credit for unfinished / splitting again and again at sprint end is one the 'our [organization's] agile ways' that immature setups adapt to almost instantly, which indicates they don't get it (yet). I've met several Orgs / teams which believed that this is one of those things you can just change without consequences, bc "agile is all stuff you can 'just' change as 'you' see fit". So basically proving to me they have no clue that they need to understand the principles and build a solid understanding before changing almost everything back, so it fits into a setup which is basically the old ways with Agile labels. My point; if you can't explain how the 'Scrummy' method / standard was holding back the Agile WoW or the org from its goals, and how the 'new' way is helping you achieve it better... Then DON'T change until you can. Feel free to expirement, but be clear on why and how you will assess if the change works. There are so many accumulated compounded downsides to doing credit for unfinished and they have a snow ball effect over time.
Whenever I get this question, I talk about the fact that story points are not about getting "credit" for work completed. Velocity is not a performance metric, it is a planning tool....THE END! Since we typically look at an average velocity over a number of sprints to plan capacity accordingly, rolling a story into the next sprint is usually a wash. I encourage teams to not talk about "credit."
This is a good working rule for a team since a team's velocity is supposed to be a measure of how much it can actually complete during a sprint. But what happens to the story that is almost done and the PO prioritizes it for the upcoming sprint --- should it be re-estimated?
I understand the want to re-estimate. The team has done work so the story should be smaller, right? But, in my opinion, the work and, more importantly, time it takes to re-estimate just isn't worth it in most cases. Bring it in to the next sprint with the same points and award the full amount of points in that sprint when it gets completed. Notice that I said to do that in most cases. I do think there's a case where it's reasonable to re-estimate. A team should re-estimate a backlog item that is being put back on the product backlog and will not be finished in the next iteration or two. In this scenario it makes sense to split the story, give the team credit for work done, and return the item to the backlog with a good estimate of work remaining.
Hi Mike! A question, In am interested in average velocity for future sprint planning regarding to this topic. So if 8 points are not finished in sprint 1, ( we are told that only 1 point is remaining) then we do not account points in sprint 1, but then in planning for sprint 2 i have a average velocity of 10 and I add all the 8 points to the sprint 2?. So then I add the 8 points (which is actually 1 point) and 9 points more in user stories, so 17 points in sprint 2? . Then mathematically speaking the average velocity would include the 8 points, then this average velocity can be more accurately used in future sprint planning to propose X points to plan I would assume? Other scenario would be to count only 1 point in sprint 2 and loose the 7 points, but the team managed somehow to do 7 points work in sprint 1, so if the average velocity is decreased, will then the team under-plan in future sprints? Thanks in advance!
Since the team did 8 points of work, you want to count that somewhere. I recommend doing it in sprint 2 in your example. This gives velocity a pessimistic bias (we know it's low for sprint 1 but aren't really sure by how much). That will generally be better (at least more conservative) when planning milestones, releases, etc. As with your other, longer question today, you're using velocity-based sprint planning. I strongly recommend capacity-based sprint planning for reasons here: www.mountaingoatsoftware.com/blog/why-i-prefer-capacity-driven-sprint-planning
I'm not saying they should do it this way but... They could move the not Done work to a new PBI. Estimate the new PBI. Subtract the points from the new PBI from the original. Reduce the Effort of the original PBI, and the team gets credit for the Done work.
A team certainly could do this. And in some cases that's fine, but most commonly a team will overestimate the work the amount finished and give themselves an artificially high velocity. That will lead to an assortment of additional problems.
You should always split the stories and take the credit. I think your argument is rather counterintuitive. Think of it like this, you could have split the story down into 1 pt tasks to start with and taken the points they completed. So why could they not split it in the end instead of beginning? I appreciate your thoughts, but you are not really staying on a single track IMO. Thanks!
I don't believe you heard what was being explained about the downsides. If you continually need to even consider if doing credit for partially finished work, then you have pain points other places in your agile setup. Working towards not even having to have this discussion will help your org work smoother, improve flow and thus predictability and the agile transition, continuous improvements asf... There are VERY valid reasons why you want to avoid this, but the Scrum guide doesn't have examples and story telling that relay why. Start with the agile principles and work upward from there. The 'credit' label even makes me jitter a bit 😀 And Merry Christmas...
@@buccaneerdk , Merry Christmas! I was listening and over the last 20 years I have tried it many ways. The least effective is to carry all of the supposedly unfinished work forward. What works best for estimation stability over time is splitting the work and leaving points behind. The reason is that it actually gives credit for work which helps normalize the estimation capacity, and it helps devs better understand the estimation of the work. Within 6 months the devs will be properly sizing work. The other method is punitive and leads to poor practices (some refer to as antipatterns). Take care and thanks for reading.
@@opensourcefreedom9241 Then we are almost on the same page. I just see way too many places where it's the M.O. to use time to split at sprint end. Which imho is then not about using the tools to add value, but a process for proces's sake. Forcing 'ourselves' to do the splits don't add much the average comes out as the same whether you have 36 in sprint a and 50 in sprint B or painstakingly comes out with 43, 43. And story points are a guideline tool not a ruler. The beauty of 'living this' imho is that you begin working as if one sprint is a chapter, which it is meant as and begin working even more focussed on iterative delivery asf. It's also all about context and scope. But there is gains by living this bit (imho) and moreso than by splitting constantly at sprint end. And thanks for reading to you too 😀
@@opensourcefreedom9241 In decades of doing it this way, I've never used it nor seen it used as punitive. Teams almost universally overstate their progress: they'll say their 80% done (and take 80%, rounding up) of the points when in reality they are less than 80% done. This leads to a higher velocity, which feels good but leads to artificially early estimates of delivery. From your comments, I suspect you plan sprints based on velocity ("we finished 18 points last sprint, let's plan 18 this time"). I find that a horrible way to plan sprints because the estimates are too imprecise and velocity itself too variable to be useful in the short term. Velocity is a great predictor in the long term when the law of big numbers can kick in and average things out. Velocity is not a good predictor over one sprint when most teams do 7-15 items.
@@MountainGoatSoftware , you shouldn't assume... My teams are massively productive and stay around 95% predictable with nearly a 100% say-do ratio. I have seen the punative methods more than most even realize. I have been practicing agile since before scrum, and my methods always work. I don't sit behind books and theory, I sit out front and lead from within the trenches. Seriously, I like a lot of your thoughts, but your estimation ideas are what I have a huge problem with.
You'll have to check the latest Scrum Alliance rules on SEUs, but I suspect you need to watch an hour of Scrum-related videos to earn a full SEU. I don't know if they track partial SEUs or if you aggregate them to collect one at a time.
Agile teams should take partial velocity credit. That is because if they are getting credit for anything related to velocity their process/framework is no longer legitimate and the transparency should allow everybody to abandon it and start being allowed to think again on product and value.
I'm not sure I follow the last half of your comment, but no, teams should normally not take partial credit for the reasons outlined in the video. When assessing their percentage done, most teams will overstate their progress. That will lead to an inflated velocity, which will likely lead to predictions of an artificially early completion.
This is great!
I recently forced a change in our approach and now we strictly recognize done items and nothing else for velocity.
It worked immediately to increase the amount of tasks completed to an all time high!
Great! I'm glad.
Thank you for the valuable insights. I have allowed few sprints for partial credit for partial completed story. Later I realized that this behaviour may lead to invalid velocity and this impacts the predictability of prod increment. I find a gap and started coaching teams to split the user stories which can be completed in shorter duration to get faster feedback in less than a day or a day during Sprint Planning and Backlog refinements.
As long as those splits and discussions happen during sprint planning and refinement sessions that sounds good
No credit for you! Been doing that from the beginning. When I get pushback, I ask, "If you took your car in for service, and it was only 85% complete, would you pay for it?"
I also make sure not to beat the team up for an occasional miss. It happens. And if I see a trend, we focus on what's getting in the team's way, not "why is Joe always late with his stories." I have needed to talk to individuals occasionally, but it's rare.
Great. I'm glad to hear our approaches are similar.
I think missing occasionally is a good sign of a team trying hard rather than playing it safe, feeling they always need to do everything.
I agree 100%.
In my experience this is also a red flag when assessing an organization's agile maturity. Giving credit for unfinished / splitting again and again at sprint end is one the 'our [organization's] agile ways' that immature setups adapt to almost instantly, which indicates they don't get it (yet). I've met several Orgs / teams which believed that this is one of those things you can just change without consequences, bc "agile is all stuff you can 'just' change as 'you' see fit". So basically proving to me they have no clue that they need to understand the principles and build a solid understanding before changing almost everything back, so it fits into a setup which is basically the old ways with Agile labels.
My point; if you can't explain how the 'Scrummy' method / standard was holding back the Agile WoW or the org from its goals, and how the 'new' way is helping you achieve it better... Then DON'T change until you can. Feel free to expirement, but be clear on why and how you will assess if the change works.
There are so many accumulated compounded downsides to doing credit for unfinished and they have a snow ball effect over time.
Great points, especially regarding explaining why and experimenting. Thanks.
I've always held to No Partial Credit. Its the only way teams will evolve properly splitting up stories before taking them into a sprint.
Great. I agree.
Whenever I get this question, I talk about the fact that story points are not about getting "credit" for work completed. Velocity is not a performance metric, it is a planning tool....THE END! Since we typically look at an average velocity over a number of sprints to plan capacity accordingly, rolling a story into the next sprint is usually a wash. I encourage teams to not talk about "credit."
100% agreed. I prefer to not use "credit" either. I do occasionally (as here) because it's how many people think about it.
This is a good working rule for a team since a team's velocity is
supposed to be a measure of how much it can actually complete during a
sprint.
But what happens to the story that is almost done and the PO prioritizes it
for the upcoming sprint --- should it be re-estimated?
I understand the want to re-estimate. The team has done work so the story should be smaller, right? But, in my opinion, the work and, more importantly, time it takes to re-estimate just isn't worth it in most cases. Bring it in to the next sprint with the same points and award the full amount of points in that sprint when it gets completed.
Notice that I said to do that in most cases. I do think there's a case where it's reasonable to re-estimate. A team should re-estimate a backlog item that is being put back on the product backlog and will not be finished in the next iteration or two. In this scenario it makes sense to split the story, give the team credit for work done, and return the item to the backlog with a good estimate of work remaining.
"It's done, just wait until the end of the day and you'll see." :D
Hi Mike! A question, In am interested in average velocity for future sprint planning regarding to this topic.
So if 8 points are not finished in sprint 1, ( we are told that only 1 point is remaining) then we do not account points in sprint 1, but then in planning for sprint 2 i have a average velocity of 10 and I add all the 8 points to the sprint 2?. So then I add the 8 points (which is actually 1 point) and 9 points more in user stories, so 17 points in sprint 2? . Then mathematically speaking the average velocity would include the 8 points, then this average velocity can be more accurately used in future sprint planning to propose X points to plan I would assume?
Other scenario would be to count only 1 point in sprint 2 and loose the 7 points, but the team managed somehow to do 7 points work in sprint 1, so if the average velocity is decreased, will then the team under-plan in future sprints?
Thanks in advance!
Since the team did 8 points of work, you want to count that somewhere. I recommend doing it in sprint 2 in your example. This gives velocity a pessimistic bias (we know it's low for sprint 1 but aren't really sure by how much). That will generally be better (at least more conservative) when planning milestones, releases, etc.
As with your other, longer question today, you're using velocity-based sprint planning. I strongly recommend capacity-based sprint planning for reasons here: www.mountaingoatsoftware.com/blog/why-i-prefer-capacity-driven-sprint-planning
I'm not saying they should do it this way but...
They could move the not Done work to a new PBI.
Estimate the new PBI.
Subtract the points from the new PBI from the original.
Reduce the Effort of the original PBI, and the team gets credit for the Done work.
A team certainly could do this. And in some cases that's fine, but most commonly a team will overestimate the work the amount finished and give themselves an artificially high velocity. That will lead to an assortment of additional problems.
You should always split the stories and take the credit. I think your argument is rather counterintuitive.
Think of it like this, you could have split the story down into 1 pt tasks to start with and taken the points they completed. So why could they not split it in the end instead of beginning?
I appreciate your thoughts, but you are not really staying on a single track IMO.
Thanks!
I don't believe you heard what was being explained about the downsides. If you continually need to even consider if doing credit for partially finished work, then you have pain points other places in your agile setup. Working towards not even having to have this discussion will help your org work smoother, improve flow and thus predictability and the agile transition, continuous improvements asf...
There are VERY valid reasons why you want to avoid this, but the Scrum guide doesn't have examples and story telling that relay why.
Start with the agile principles and work upward from there.
The 'credit' label even makes me jitter a bit 😀
And Merry Christmas...
@@buccaneerdk , Merry Christmas!
I was listening and over the last 20 years I have tried it many ways. The least effective is to carry all of the supposedly unfinished work forward.
What works best for estimation stability over time is splitting the work and leaving points behind. The reason is that it actually gives credit for work which helps normalize the estimation capacity, and it helps devs better understand the estimation of the work. Within 6 months the devs will be properly sizing work. The other method is punitive and leads to poor practices (some refer to as antipatterns).
Take care and thanks for reading.
@@opensourcefreedom9241 Then we are almost on the same page.
I just see way too many places where it's the M.O. to use time to split at sprint end.
Which imho is then not about using the tools to add value, but a process for proces's sake.
Forcing 'ourselves' to do the splits don't add much the average comes out as the same whether you have 36 in sprint a and 50 in sprint B or painstakingly comes out with 43, 43. And story points are a guideline tool not a ruler.
The beauty of 'living this' imho is that you begin working as if one sprint is a chapter, which it is meant as and begin working even more focussed on iterative delivery asf.
It's also all about context and scope. But there is gains by living this bit (imho) and moreso than by splitting constantly at sprint end.
And thanks for reading to you too 😀
@@opensourcefreedom9241 In decades of doing it this way, I've never used it nor seen it used as punitive. Teams almost universally overstate their progress: they'll say their 80% done (and take 80%, rounding up) of the points when in reality they are less than 80% done. This leads to a higher velocity, which feels good but leads to artificially early estimates of delivery.
From your comments, I suspect you plan sprints based on velocity ("we finished 18 points last sprint, let's plan 18 this time"). I find that a horrible way to plan sprints because the estimates are too imprecise and velocity itself too variable to be useful in the short term. Velocity is a great predictor in the long term when the law of big numbers can kick in and average things out. Velocity is not a good predictor over one sprint when most teams do 7-15 items.
@@MountainGoatSoftware , you shouldn't assume...
My teams are massively productive and stay around 95% predictable with nearly a 100% say-do ratio.
I have seen the punative methods more than most even realize.
I have been practicing agile since before scrum, and my methods always work. I don't sit behind books and theory, I sit out front and lead from within the trenches.
Seriously, I like a lot of your thoughts, but your estimation ideas are what I have a huge problem with.
Did I just earn an SEU by watching this video entirely?
You'll have to check the latest Scrum Alliance rules on SEUs, but I suspect you need to watch an hour of Scrum-related videos to earn a full SEU. I don't know if they track partial SEUs or if you aggregate them to collect one at a time.
Agile teams should take partial velocity credit. That is because if they are getting credit for anything related to velocity their process/framework is no longer legitimate and the transparency should allow everybody to abandon it and start being allowed to think again on product and value.
I'm not sure I follow the last half of your comment, but no, teams should normally not take partial credit for the reasons outlined in the video. When assessing their percentage done, most teams will overstate their progress. That will lead to an inflated velocity, which will likely lead to predictions of an artificially early completion.