1

When we close a sprint containing issues in progress (partly finished), should we split these issues.. so jira knows how many story points are done in the closed sprint.

When we don't do this:

  • moving these issues to next sprint will suggest all story points are belonging to next sprint
  • or when we update-estimations of remaining work, all storypoints done in previous sprint will be gone.

What is the correct way to administrate the story points of 'In Progress' (partly finished) issues when closing the sprint.

Raymond Domingo
  • 173
  • 2
  • 9

3 Answers3

0

I'm assuming you are using the Scrum framework.

In Scrum we focus on a team's ability to get things done. A good way for a team to measure this is to use story points and to measure velocity. The velocity is a rolling average of the number of story points that the team has got done in the past few sprints.

If you follow this approach then when a story is not done in a sprint then no story points for that story will be associated with that sprint.

There is some debate about what happens to stories that get carried over to the next sprint. Some teams will re-estimate them based on how much work they think is remaining. Other teams think of this re-estimating as a form of waste and will simply move the story to the new sprint with the original story point estimate.

Remember that the velocity is a rolling average, so it doesn't particularly matter when the story points are counted.

This approach may feel uncomfortable. This is because it is human nature to associate story points with effort, rather than work that is done. However, you will find that in the long-run this approach will allow you to determine your team's capacity to get work done in a sprint, which is a good way to measure progress.

Barnaby Golden
  • 4,176
  • 1
  • 23
  • 28
0

I agree with Barnaby Golden. In addition to his comments based on Scrum, if the story can be split based on your Definition of Done criteria and Acceptance Criteria , the only role that might approve to split the story is the product owner. While approving, the product owner should consider two things: 1- if there is value achieved with the approved part of the story 2- if the approved part can be added as an increment to the product that will be delivered.

I do not recommend splitting stories to increase your story points, in other words, velocity.

Virtue
  • 1
0

Why?

If you do it for planning: why bother? Put it back on the product backlog, and when picking it for a later sprint, keep in mind you already worked on the item. You only estimate because you want to pick a number of items that fit in your sprint, so it doesn't matter what the story points were.

If you want to split the story points to calculate team performance: please stop using velocity as a performance metric.

If you want to "correctly" divide story points to decide how much of the work is done: this item is not "done", so it has no value.

ankhayra
  • 1
  • 1