I'm looking for some advice or suggestions as to the optimal approach for partially complete rollover stories and velocity calculation.
Let's say a developer picks up a 5 point story near the end of Sprint 1. At the end of the sprint, they estimate that they have completed 2 out of the 5 points. However, when the sprint is ended, the story (and all 5 of it's points) will be moved in to Sprint 2. Assuming this is the only story in Sprint 1 the velocity for this developer according to JIRA will be:
This is causing the following problems
You have misunderstood what scrum estimation is for and how it works.
The mistake here is "partially complete rollover" - this is nonsense and does not exist in Scrum. When you bring an item into a sprint, you are committing to completing it in that sprint. At the end of the sprint, the item is either done or is not.
If an item is say 5 story points, it doesn't matter if you think you've got 1 point in or 4, you can't tell your product owners that it is done.
The way to "fix" this is to use the estimates as intended:
Yep this makes sense. It's the right way to do it for sure. Was curious if JIRA supported the wrong way to do it as well. No matter, we'll continue to get better at capacity planning outside of JIRA (in spreadsheets) so we don't take on as much work, and JIRA works as designed.
Solution tl;dr: Work to get better at planning sprints to reduce rollover and then the JIRA rules around sprints and calculating story points (velocity/burndown) will work for you.
My question would be, do you then reestimate the issue for the new sprint. So for e.g. three developers are picking up issues with 5 SP's on the last day. They all don't finish this issue. I complete the sprint and the amount of work done in this sprint isn't counted to this sprint velocity. Fine by me but what now? We now have three issues of 5 SP's rollover into the new sprint. Do we reestimate based on the work done or keep it at 5 SP per issue?
Its a hack but you can reestimate what is left, record what was done in the notes, change points temporarily to whats left, finish the next sprint, and then reassign all the points before completing the second sprint. So the points are all counted in the second sprint, but for planning sprint 2 you can see in dashboards and reports that you are targeting the right number of points. I understand the argument that is made on thread after thread which boils down to "scrum doesn't do that", but I think there is a big caveat the proponents of never splitting points fail to bring up. ... Lets say in sprint2 you had a 13 point story that only had 1 point left for validation but didn't get finished but all agreed should be finished in the next sprint. Every group I know of would somehow assume the cognitive burden of realizing while the 13 points is being moved to sprint2, the team could really take on an additional ~12 points of work than normal because its almost done. Its frustrating to me that so many agile proponents are rigid in this philosophy to the degree that they do not allow tools to take on this cognitive burden if a team so chooses. At worst Im wrong and its a less desirable practice you are enabling people to choose if they want.
That completely misses the point of doing Scrum estimates.
It's not the wrong thing to do, if it suits you, but all I'd advise there is acknowledging that you're no longer doing Scrum and hence there are some things in the Scrum tool (Jira Software) that are not going to be useful to you any more.
I agree with Nic.
JIRA was not designed to be a SP tracker. You use the team's SP velocity (totals SP per sprint trend over time) and actual SP budget (adjusted for people on leave during next sprint, etc) to determine how many SPs can be loaded. The total SPs per sprint is to help the team understand what they can realistically complete during the sprint.
If the team cannot finish the agreed total SPs by the end of the sprint, then Nic has identified the ways to address this problem for the next sprint.
After several sprints, the team will find the most realistic number of SPs which can be loaded.
I don't disagree that the accepted answer is the "right way to scrum", but it doesn't actually answer the question of how to handle this unfortunate, and sometimes unavoidable circumstance during sprint planning.
If you have a 5-point story someone worked on, and the end of the last day comes around, and they just weren't able to complete it... what is the best thing to do with that ticket?
Without being a Scrum expert myself, I would argue that the best way to look at it is to acknowledge two things:
1. Your team did not finish the ticket (therefore, the points should not be included in your Sprint 1 velocity)
2. The ticket now only has 1 point of work to be completed in whatever sprint you put it in.
Therefore, if you want to encourage good Scrum practices, I would just update the ticket with the new estimate, and accept the previous work as 0-velocity for the sprint in which it was done. As you get better at splitting, estimating and completing tickets, your velocity will increase as less points are lost this way - and this is a relatively accurate reflection of the effectiveness of your sprint.
Keep in mind, points are not currency! You don't actually lose any money or progress by acknowledging that the ticket wasn't completed in the sprint - you just gain a more accurate metric of complete work (vs incomplete work). This is part of the learning curve of adopting Scrum - it's not unusual or unexpected (I bet every commenter on this thread has had the same problem recently), and don't let anyone feel bad for "losing points" - focus on improving your process, not expecting perfection.
Eventually you may learn that "more often than not, we can't complete a 5-point ticket in a sprint" - in which case, maybe you need to increase all your estimates and split your tickets! Or maybe you need to reduce your meetings, or maybe you need to take a closer look at 5-point tickets to confirm the points, or refine the requirements before accepting them into the sprint. Whatever you learn, it's an improvement! And this way your velocity will improve with it :)
To be fair, here's a good analysis that disagrees with re-estimating, and argues for simply leaving the estimate as it was (even if you think you have a better estimate now):
Either way makes sense, depending on your preference - and you can choose either one! Just avoid the temptation to assign "partial credit" just because someone spent time on the ticket.
>how to handle this unfortunate, and sometimes unavoidable circumstance.
It's not in the slightest bit unavoidable. You shouldn't be doing it. Changing the estimate on an issue denigrates what the team have been doing, and destroys your reporting and estimation system.
Sorry if this was unclear: I wasn't saying changing the estimate is unavoidable. I was saying arriving at the end of a sprint with an incomplete ticket is sometimes unavoidable (due to unpredictable circumstances), which is just to point out that it's not wrong to ask for a reasonable way to handle that situation.
It sounds like your answer would be "leave the points alone, and count them in whatever sprint you actually complete the ticket" as in the premise of the original post - which also sounds reasonable (your answer just didn't say that explicitly). The Scrum guide does talk about re-estimating partially complete tickets in the case of a Sprint cancellation, so I believe that is also a reasonable solution. To me it depends on whether you care more about planning/short-term accuracy or historical/long-term accuracy (who looks at the numbers and what they expect and care about, etc).
👋 Hi there Jira Community! A few months ago we shared with you plans around renaming epics in your company-managed projects. As part of these changes, we highlighted upcoming changes to epics on...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events