Skip to main content

Sprint Rollover

Last post 08:18 pm November 30, 2016 by Timothy Baffa
5 replies
10:36 pm November 29, 2016

Sprint planning and reducing sprint 'roll over' is a challenge at times for our teams. We distill epics into stories, estimate the stories, but the story inevitably has numerous sub-tasks that speak to writing code, writing test plans, functional testing, unit test writing, accessibility testing, etc.

So a story may have an estimate of 3 story points for the dev work portion, but all the other related sub-tasks have estimates which sum up to let's say 13 story points. And for discussion sake, let's say our sprint velocity is 10 story points.

We often find that we pull this story into a sprint, but not all the sub-tasks can be completed by end of sprint. Thus we must roll over the story into the next sprint.

We use JIRA and are finding that when you roll over a story from one sprint to another, it fails to report out proper velocity for the sprint just completed. Conversely, if we divide up all the sub-tasks into related stories, the common workflow we use in JIRA has steps like 'ready for testing' and 'released' which does not work well if we were to convert a qa test case sub-task into a story.

Curious how others may address this planning and logistics issue? Do teams roll up all these sub-tasks as stories into a single Epic for example?

Thanks.


05:42 pm November 30, 2016

You mentioned a story might have 3sp for dev and other sub tasks make it add up to 13. This may be where you're running into the issue.

A story should only have a single story point estimate for the entire story. So from a whole-team discussion using something like Planning Poker, the team may decide that the whole story (including everything needed to meet its acceptance criteria) is say a 13. If you like, you can add hours to the tasks (but these are unrelated to the story's estimate). If your velocity is 10, you're not likely to get that single story done so its probably too big (over a week is generally too big for a story), so you should see if it can be sliced smaller.

Scrum (and by association JIRA) will only count fully completed stories against that sprint's velocity. So if you just have 1 story, which is 13 points and its not complete, the velocity is 0.

I would recommend focusing on the story (as a user, I want to, so that) and seeing can you break it into thinner slices which can deliver value independently.


06:29 pm November 30, 2016

> We often find that we pull this story into a sprint, but not all the sub-tasks can be
> completed by end of sprint. Thus we must roll over the story into the next sprint.

What does this mean for the team's ability to meet the Sprint Goal?

Remember that if the team cannot commit to the Sprint Goal, then they should not plan the associated body of work into their Sprint Backlog at all.

Also, in Scrum, no work is ever "rolled over" into another Sprint. Undone work remains on the Product Backlog, where it can be re-ordered by the PO so as to maximize the delivery of product value. It may or may not be planned into a future Sprint.


06:39 pm November 30, 2016

Thanks for the feedback. I agree with everything your stating philosophically, my question really centers around the implementation aspects. Meaning, we have a sprint goal of let's say 50 story points. This 50 story points is made up of let's say 5 stories. In this case, each story has a set of sub tasks. Some sub-tasks owned by developers, others by analysts and others by qa. If the analyst and dev tasks are completed, but the qa tasks remain at the end of the sprint, those tasks must go into the backlog and/or make their way into another sprint. When that happens, the progress made against that story is not well represented in the sprint where it started (b/c of how JIRA works). My question centers around what are some real-world, best practices for how a team should define a 'story' and its related tasks so that a story can be effectively completed within a sprint and the time spent on it counts towards the sprint's velocity.

From the prior post, it sounds like the simple answer is to further distill the story so it can fit into a sprint. And in the case where dev work on the story can be completed, but qa work cannot, it sounds like the suggestion would be to not pull the story into the sprint because it wont fit. But if the team wants to make the most out of the time they have, is there a cleaner way to work on the dev aspects of the story and schedule the qa work for the next sprint and at the same time, not carry over the story from one sprint to the next and give the current sprint's velocity credit for the work that was done within it (using JIRA)?

Hope that clarifies.

Thanks.


07:42 pm November 30, 2016

> In this case, each story has a set of sub tasks. Some sub-tasks owned
> by developers, others by analysts and others by qa.
> ...
> My question centers around what are some real-world, best practices
> for how a team should define a 'story' and its related tasks so that a
> story can be effectively completed within a sprint...

One real-world, best practice in Scrum is to challenge the assumption that sub-tasks are "owned" by developers, analysts, or quality assurance. In Scrum, the work should be owned by the Development Team. That is the role. In an efficient team, people are able to go to where the work is, instead of waiting for the work to come to them based on particular skill-sets. In other words, the challenge is perhaps the harder one of attaining better cross-functional skills, rather than adjusting user stories.


08:18 pm November 30, 2016

Jonathan,

Instead of worrying about "getting credit" for work done in a sprint, turn your focus to what can be done to completework in a sprint.

From a velocity standpoint, it all equals out if an incomplete story is re-offered in a subsequent sprint and completed. By no means should the team waste any time carving out the completed parts/tasks of a story from the incomplete ones. This is incredibly wasteful. By no means should you divide stories according to workflow (development/testing/release).

A story is only meaningful if it is complete according to the DoD, and it can be provided (released) to the end-user. Any partial completion towards that goal is irrelevant.

There have been several posts already providing valuable advice on best practices for managing sprint work. Please take them to heart.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.