nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Spill Over Stories

Jackie Gonzalez

I am looking for information/advice on what to do with stories that spill over from one sprint to another. Sometimes because the team committed but did not complete, and sometimes because we took on a stretch story at the end of a sprint and did not complete it.

Specifically, I'd like advice on how to handle the reporting side of things. At the end of a sprint, we look at how much our original time estimates were versus how many hours were added/reduced (using work logs). If I remove a story from the sprint, and move it to the next, however, that story and its subtasks, worklogs etc. don't appear in reports on the original sprint.

Additionally, if I report on number of hours worked during the new sprint, the total work on each task/story is including time logged from the previous sprint.

I am new to Jira so any help would be great.

Thanks

jackie

Accepted answers

Ruiz_ Preston

Hi Jackie,

My reccomendation is to NOT remove the story from the sprint; instead, use Greenhopper's default process of carrying over incomplete stories.

When the sprint ends, use the gear icon next to the sprint name to "Complete Sprint". A warning will pop-up that indicates the number of incomplete stories/subtasks that are still in that sprint. Upon acknowledging this, the sprint will close and the incomplete stories will automatically appear at the top of the backlog. The original points, time (estimated and logged), etc. will remain on the user story (and I believe each subtask will remain in the correct status - for example, if two subtasks were complete, they will remain complete when the story is carried over).

In terms of sprint reporting, if you use the "Report" screen in Greenhopper, you will be able sto see any sprint with the "Sprint Report". This report will show a burndown chart, but perhaps more importantly for your needs, you will see a list of completed and incomplete stories for that sprint.

To track when time was increased or logged to a task/story, you may find the "Burndown Char" beneficial. Below the chart, you will see a list of events that have been tracked for the sprint (including "worked logged" and "RTE Change" [remaining time estimate change]). Of course, you can always view the story/subtask and look at the Work Log and History Information located under the "Activty" header at the very bottom of the story/subtask.

Hope this helps.

One question... Are you tracking/reporting your point velocity for each sprint? If so, you will want to also understand how Greenhopper hanldes points for stories that are carried over. You will not get credit/points for any incomplete stories in that sprint. Instead, you earn the points at the time the story is closed. Be cautious with how you re-estimate the remaining work for a carry over story. For example, let's take a 5 point story. If this story is not completed in the sprint, none of the points (even if subtasks were completed) will be awarded for the sprint. When the story is brought into a new sprint, you and your team may decide that a good portion of the story was already complete (let's just say "3 points worth"), so the remaining work could be estimated at 2 points. You may be tempted to adjust the point value down to reflect the remaining work for the new sprint, but be warned... If you want credit for the entire value of the story (all 5 points), you must keep the original point value assigned to the story when you start the new sprint. Although you may be able to edit the story (including the point value field) once the sprint starts, the Greenhopper Velocity Report will not use the new point value.

Let me know if you need clarification on any of the information here.

Thanks and good luck,

Preston

All comments

Ruiz_ Preston

Hi Jackie,

My reccomendation is to NOT remove the story from the sprint; instead, use Greenhopper's default process of carrying over incomplete stories.

Hope this helps.

Let me know if you need clarification on any of the information here.

Thanks and good luck,

Preston

James Strangeway

Yea, I have had to deal with this as well. I have figured that the overall velocity will balance out over time Where one sprint might be over stated with some of the work from story that gets completed in the next sprint where that sprint gets all the credit. You can decide to make a note of it and just communicate it when necessary or know that the velocity will average out over several sprints.

Jackie Gonzalez

Very helpful. Thanks! To answer your question Preston, we are tracking/reporting point velocity for each sprint. Right now, we are not changing the original story points for any stories that carry over for the exact reason you specified. Our velocity has some pretty sharp drops/rises as a result but the average velocity is what we are focusing on and it has remained fairly consistent. We are still a pretty new scrum team.

Question - do you know if there is a way to query worklogs for a particular date range for stories in a sprint? We have the Tempo add-on but it seems if I want to get a simple report showing Parent, Subtask, Hours Estimated For Sprint, Hours Logged for Sprint, I have to export the data into Excel and do alot of manipulating (pivot chart) to get those aggregates. Am I missing something?

Thanks again,

Jackie

Jackie Gonzalez

I don't think I can use a filter because they only filter at the issue level, not the worklog level. When I run a query/filter it will tell me the aggregate hours logged on a task/story but I can't tell when those hours were logged (this sprint or previous sprint). It would be nice if I could filter on the date of the worklog entry but to my knowledge I can't do that.

James Strangeway

Hi Jackie, Could you use a filter?

David Pinn

What you are interested in is the number of stories completed per sprint on average. Over several weeks, it will not matter that some stories are reported against one sprint even though they were started in the previous sprint.

Keep your stories as small ('small-grained') as possible so as to minimise the relative size of the portion of the work that spills from one sprint to the next.

Marc Moroz

There should be a way of noting that this was "solved" via an add-in.

We should be able to distinguish between purchasing a solution vs. getting this to work within vanilla JIRA.

Sandy Slatter

@Ruiz_ Preston In your 5 points / 3 points example above, that the estimated remaining 2 points spills over into the next sprint......how do you account for accurate team member allocation to verify over/under loading someone with enough new work? It appears as the team member is assigned 5 points, when reality is they are only assigned 2 points to complete the remaining work in the upcoming new sprint? Have you found an easy way to track the remaining work points per Story or per Assignee in planning out the new sprint?

I agree, with not adjusting the original story point estimate and counting the story "done" when all work is complete in the next sprint, but am struggling with the original points vs. remaining work points when planning the next sprint. Any help is appreciated.

Thank you!

Sandy

Bhupendra Singh_xrbqxe

That's why time estimates tracking (using fields Original Estimate, TimeSpent, Remaining Estimate, Σ Original Estimate, Σ Remaining Estimate fields is the best way to estimate and track). At the end of every sprint, net sprint planning will be based on Remaining Estimate of the items. For new items, Remaining Estimate will be same as Original Estimate. For spilled over and partially completed items, the values will be different.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-software

jira-administration

report

story