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.
G’day Bamboo customers, As we approach GA for Bamboo Data Center , we would like to inform you that the Data Center Apps Program for Bamboo starts this quarter. How long does it take? We are g...
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