Attributing Story Points for Partially Complete Rollover Stories

Paul Volk September 28, 2018

Background:

I'm looking for some advice or suggestions as to the optimal approach for partially complete rollover stories and velocity calculation.

Scenario:

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:

  • Sprint 1: 0 points
  • Sprint 2: 5 points

Issue:

This is causing the following problems

  1. The developers velocity is not accurate from sprint to sprint. The reality is they completed 2 points, then 3 points in each respective sprint. But JIRA considers it 0 and 5 respectively.
    1. This also causes inaccurate reporting at the end of the sprint, making it appear that this developer did literally nothing in sprint 1.
  2. It's not clear how many points are actually in Sprint 2 at the start of the sprint, forcing capacity calculation to occur manually.  e.g. It appears to be 5 points but really, it's only 3 points.

Solution:

  • That's what I'm hoping the community can help with! Hopefully it's an obvious solution that I've simply overlooked :) -- Thanks in advance!

7 answers

1 accepted

2 votes
Answer accepted
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
September 29, 2018

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:

  • If you regularly take too many points into a sprint so that things don't get done, stop committing to too much, and reduce the points you take in.  (Or lengthen the sprint to allow more to be done)
  • If you find stories don't fit into sprints, split them into more manageable chunks before going into the sprint and only take in the chunks you can do
  • Get better at estimating, so that you don't commit to items that won't fit
Paul Volk October 1, 2018

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.

Like # people like this
mart_bogdan February 18, 2021

That's cool in ideal world.

 

But we live in real world with distributed team on part-time. And agile in terms of new tasks are spawning all the time, But we need to track team velocity somehow.

Like # people like this
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 18, 2021

Yes, and that's what Agile does.  I'm not sure what you're saying here.

Sam Huizeling March 12, 2021

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?

Like Sage Arbor likes this
Sage Arbor May 6, 2021

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.  

Like # people like this
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
May 6, 2021

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.

Like Peter likes this
Miklos Blasko
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
November 30, 2023

it's not a great answer to this problem. 

I can see several reasons why someone would like to note down the finished SPs of a Jira ticket:

  • planning: you need to plan with your actual capacity so you need to write down somewhere the already completed work and substract it from the total amount of SPs of the sprint you are planning
    • this is very common and everyone does it, so why is there no field supporting this?
  • measuring the performance of the team and the quality of estimations
    • I want to know how many SPs the team actually completed in a sprint. I want to know it because I want to calculate with accurate velocity. Sometimes tickets get rolled over not just once but even twice, so it would take three sprints for those SPs to show up in your velocity reports. Until then, if you're counting only closed tickets, you will be losing velocity that your team actually has. 
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
December 6, 2023

All of the points here are screaming that you are trying to do waterfall project management with a Scrum tool.  I would recommend revising what Scrum is and talking to a scrum master about how you plan and estimate during Scrum processes.

solsbarry December 6, 2023

Maybe there could be a setting to unlock non-agile features, where you check a box attesting that "My company only wants to say they do Agile development, but in reality they are stuck doing waterfall methodology. They use Jira to give the appearance of an Agile methodology, but JIRA isn't working for us because we don't use it properly, so please unlock these features that we want so we can continue being inefficient". We would definitely check that box where I work.

1 vote
Joseph Marty (Contractor) June 21, 2022

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 :)

Joseph Marty (Contractor) June 21, 2022

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):

https://www.mountaingoatsoftware.com/blog/should-you-re-estimate-unfinished-stories

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.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 21, 2022

Um.

>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.  

Like Dima Diachenko likes this
Joseph Marty (Contractor) June 21, 2022

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).

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 21, 2022

Ah, I see.

The way to handle it in a reasonable way is to roll it all over to the next sprint.  Anything else destroys your reporting and estimation capabilities.

1 vote
Troy Spetz October 1, 2018

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.

0 votes
Vikram Suthar
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
March 21, 2024

NA

0 votes
Vikram Suthar
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
March 21, 2024

In agile development, estimations are crucial for planning and tracking progress. However, there are instances where estimations may not align perfectly with the actual work completed, leading to challenges in accurately measuring team velocity. Let's delve into a couple of scenarios where estimations might deviate from reality.

Firstly, consider a situation where a team is working on implementing a complex functionality within a project. Despite thorough planning and estimation, unforeseen complexities arise during implementation, leading to delays in completing certain tasks. For instance, the team might encounter unexpected intricacies within programming language frameworks or other technical dependencies. Such unforeseen challenges can disrupt the original estimates, causing deviations in sprint planning and velocity tracking.

Additionally, unforeseen events such as production issues or outages can disrupt the sprint's rhythm, leading to spill-over stories and incomplete tasks. Despite incorporating buffer points for such contingencies, the unpredictable nature of these events can still impact sprint commitments and velocity calculations. Moreover, in the case of new projects, anticipating every potential issue or setback becomes inherently challenging, further complicating accurate estimation and planning.

In essence, while it's essential to strive for accurate estimations, it's equally vital to acknowledge the inherent uncertainty and complexity of software development. Despite efforts to incorporate buffers and contingencies, deviations from estimates can occur due to various factors beyond the team's control. Therefore, rigidly adhering to initial estimates without considering the dynamic nature of software development may not always be practical or conducive to effective project management.

In such scenarios, it becomes imperative to adopt a flexible mindset and leverage agile methodologies to adapt to changing circumstances. This may involve reevaluating estimations based on new insights gained during the sprint, recalibrating sprint commitments accordingly, and continuously refining estimation practices to improve accuracy over time. By embracing agility and responsiveness, teams can navigate uncertainties more effectively and drive towards successful project outcomes.

0 votes
Jones, Ryan (R.G.) November 20, 2023

"But carry-over points makes them ideal for estimating new sprints.  Because when you carry over an issue, you know that you've failed somewhere, and you need to examine why. "

Totally agree.

If you do partial completion, you have no way to know something is wrong. --I disagree, you carried over a story, hence you know something is wrong.

"Partial completion is complete failure, it makes a nonsense of bothering to estimate, calculate velocity, and review and improve your processes."

Why?

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
December 6, 2023

Because a partial completion means your team has failed (quite probably for reasons beyond their control).  If you allow partial completion as a normality, you are not going to be reviewing why there was a failure, so your team are not going to improve, and you can't measure estimation, capacity, or what your team can deal with.

0 votes
Jones, Ryan (R.G.) November 20, 2023

Whats the point of story points? One primary purpose is so the team can measure its velocity and use it to plan an appropriate amount of work. 

If the team has closed all their stories, great. Now they can use the velocity to plan to take on some number of story points. Lets say, they do not complete all work and must carry over some storries.  Now they cannot use points to estimate the capacity for the new sprint. 

Now I agree, reducing the point totals for the carry over work destroys the estimation in the long run, because now we dont know we cant track velcoity.

But the existence carryover work makes story points useless for estimating new sprints.

And theres the rub, the current system doesnt provide a method to make use of story points for estimation, in the event of carry over work.

Some type of partial completion for planning, would be a useful feature. So that the team can still use their velocity to plan for an appropriate number of new points to take on. It doesnt need to destroy estimation, it doesnt need to effect estimation. Leave the current stroy points in place, dont touch them at all, let them get recorded when the ticket is truely done and closed but add a field for partial completion of points and provide a total of the partial points left in the sprint, and now we can use that number to plan for the next sprint. 

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 20, 2023

Welcome to the Atlassian Community!

No, that's not right.

Story points are for estimating primarily.  They are used to show relative sizing of cards.  Their secondary use is to you a velocity, which informs the team on what they should be drawing into sprints.

But carry-over points makes them ideal for estimating new sprints.  Because when you carry over an issue, you know that you've failed somewhere, and you need to examine why.  

If you do partial completion, you have no way to know something is wrong.  

Partial completion is complete failure, it makes a nonsense of bothering to estimate, calculate velocity, and review and improve your processes.

Jones, Ryan (R.G.) November 20, 2023

I agree with alot of what you say, but not the conclusion you are drawing.

"Story points are for estimating primarily."

Agree, they for esimating the work that can be brought into a new sprint.

"But carry-over points makes them ideal for estimating new sprints.  Because when you carry over an issue, you know that you've failed somewhere, and you need to examine why.  "

Totally agree.


"If you do partial completion, you have no way to know something is wrong."  

Its very vissible when tickets carry over, so you know something is wrong.

"Partial completion is complete failure, it makes a nonsense of bothering to estimate, calculate velocity, and review and improve your processes."

This seems a very dogmatic response that you havnt supported very well. What about partial completion would reduce the effectiveness of estimation, affect the calcualtion of velocity, or reduce our ability to  review and imporve process?

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 20, 2023

If you do partial completion, that becomes estimation at a different level, which renders your overall estimation process pretty much pointless.

Velocity is a binary value - done or not done.  There's no in-between, by definition, there cannot be.   If you're going to do partial completion, you might as well forget velocity, as well as timeboxing things into sprints.  A better representation would be Kanban with estimates (i.e. non-agile estimation, although the process could remain agile).  You would be moving to measuring throughput, rather than velocity.

Without sprints, you lose the easy way to see problems occuring.

Suggest an answer

Log in or Sign up to answer