JIRA Agile Completing a sprint - stories not complete - roll forward or break apart?

shauntck February 16, 2015

Hi guys, I'm trying to figure out what people do when user stories are not complete at the end of a sprint? Do you guys typically roll the issues forward (known as option A) into the next sprint (assuming they are still top priority of course)? Do you then change the estimate how much is left? or break them apart into pieces that got done and those that didn't only move the ones that were complete forward (option B)?

Both options pose some problems from a reporting standpoint for me and i'm not quite sure what others do.

Option A - faster, easier. However, we use story points (1 point = 1 day of work basically). We use the Sum of Hours metric on the tile to kind of get a quick gauge as to how something is coming along in a sprint. Now, the metric is showing total time for the issue and doesn't really give me a sense as to how close it is to being done. For example - say I have Sprint 1 - Story 1 - Estimate 1 day. Worked 10 hours so far and isn't done. Sprint 2 now shows 10 hours + any time worked that sprint and you sorta lose the quick gauge at how close we are (although perhaps i just shouldn't care about that and use the standup to gather this info). Also, because we probably re-estimated based on what is remaining - now the estimate is saying the story is work a fraction of what it actually was - so you kinda lose the "estimate vs actual" on an individual story metric.

 

Option B - this is a bit more what actually got done but then you sorta lose your "what you shot for" vs "what you actually hit" metric... Also, this approach means you're doing a lot of slicing and dicing of stories which can be kinda tedious plus it kinda feels like you are cheating - we didn't get it done so let's break it apart and change the story so it looks like did... ya know?

 

Anyways, just trying to think through this a bit and wondering if anyone else has any good ideas as to how they manage this. Currently, i'm leaning towards option A as the historical is less valuable for me than the here and now (not to mention the speed).

And yes - of course the best option here is estimate perfectly and get everything done you expected - however, in practice I haven't found that crystal ball... 

Thoughts? How do you guys do this sort of thing?

 

2 answers

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question

1 vote
PeteToscano April 22, 2015

This is an issue our PM and I have been talking about for a while. Right now, we estimate that a story will be X story points for this coming sprint. If, when we finish the sprint, the story is not done, we (usually) roll it over to the next sprint and re-estimate the story points left. This re-estimate, Y, will be the new point value for this story. (X is almost always greater than Y.) 

As you stated, though, this doesn't quite feel right. Even though (X - Y) points were effectively done for this story on the just finished sprint – this is definitely debatable, though – the team doesn't get credit for that work. It could be argued that since the story isn't actually done, the team doesn't get those points; they only get credit for the points done, not the points worked (if that makes any sense). The velocity calculated doesn't necessarily reflect the points worked, it represents some mix of points worked and their ability to accurately estimate. 

Worse in my mind, though, is that when the story is finally done, the final point value on this story doesn't actually reflect the work done. If the example story above is completed in the next sprint for Y points, then it looks like this story took Y points of effort, when X is the more appropriate value to consider when looking at the effort involved for the whole story vs the effort involved for this story in this sprint. 

Maybe the solution for this is to create a custom field. Keep the points field, but add an "original points" or "total points" field. This new field would track all the points applied to this story across however many sprints it's worked. The team gets credit for however many points the last estimate is when the story is truly finished – Y, in the example above – but the story itself would be considered to take X points.

This all assumes that the original estimate is immutable and that subsequent re-estimates of the story are more a matter of subtracting the work done in previous sprints. In reality, this probably isn't the case. Every re-estimation is a mix of subtracting the previous sprint's work and re-estimating the remaining work involved. Maybe this is one of the reasons why the agile texts that I've read and the training that I've been to suggest that story points shouldn't be tied to any definite time measure? If the team says that a story takes X points, it takes X points, regardless of how long or how much effort it takes. 

So, this "thinking out loud" has kind of made me think that having the custom field for "original estimate" is the way to go. The primary use of story points is to help guide the product owner in choosing appropriate stories to be included in the next sprint, so it's in everyone's best interest to make sure that the estimates are accurate going into sprint planning. Any further metrics, such as velocity and "total story effort" fall in behind this in priority

1 vote
Ivar
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 25, 2015

Our definition of done says that an issue should be code complete, documentation complete (if applicable) and test complete. If there are any open bugs found by QA, and the end of iteration is reached, the issue is not approved as part of the release, and the code is removed from the branch. If we add it to the following sprint depends on the priority (if it has changed). 

Now - we're not spending that much time on the estimates as such because we're more focused on burning the story points. But the process is - when stopping progress on a task - and there is more work to do - remaining work is added. So, if the estimate was 10 hours, and there are 3 hours of additional (e.g. total of 13), this is added on the issue. Where the hours are burned, e.g. in the first or the following sprint, is not important to me as a pm. Btw - I never check logged hours vs. story points. 

I would use the stand up meeting to keep track. Hours, as you point out, will only make sense when an estimate is accurate. And you do not know the accuracy before the issue reaches resolved|closed state: 

  • Original estimate: 10 hours. half way through, you believe you're 50 % complete. 
  • Used time: 10 hours. Additional estimate: 3 hours. Total estimate 13 hours. You now believe you are 77 % complete. 
  • Used time: 13 hours. Additional estimate: 5 hours. Total estimate 18 hours. You now believe you are 72 % complete. 

What you might ask yourself - in the agile/lean spirit - does this "gauging" provide value to the team, or would it be better to focus on the communication within the team? 

 

TAGS
AUG Leaders

Atlassian Community Events