Sprint Rollover

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.

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

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.

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

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.