Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Attributing Story Points for Partially Complete Rollover Stories

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!

2 answers

1 accepted

1 vote
Answer accepted

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

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.

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.

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

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

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 Gera Aksenov likes this

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.

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Bamboo

Bamboo Data Center Apps Program coming soon

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

63 views 0 6
Read article

Community Events

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

Events near you