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.
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,
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.
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.
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?
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.
As a Belgian, beer-lover and home brewer, beer is one of my great passions. I love the fact that with just a few ingredients (usually just water, hop and malt) you can create so many different tastes...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot