Determining "Complete" states for Velocity view

Ernest Mueller February 3, 2014

We have an issue in that our release schedule is not completely linked up with our sprint schedule. We have biweekly sprints and weekly releases, but stories that get to code complete have to go through a week of testing and release to go out. Our definition of done says that you can't close a ticket until it's actually out in production and in use.

This affects the Velocity chart in that it always shows overcommitment as a result.

Let's say the team can do 100 story points a sprint, but at the end of each sprint there's about 30 points of stories that don't close, but slide into the next sprint. But next sprint, they can accomplish another 100 points of work - so the sprint "has" 130 points in it. They complete 100 and slide 30 waiting on release, and then the velocity chart always looks like an overcommitment of 130 and only delivering 100.

The simplest fix for this is to be able to configure a set of ticket statuses that count as done from the velocity chart perspective. We'd basically say that Ready for Release, Resolved, and Closed are the states which would be "done" from a velocity point of view. This would allow us to not improperly close tickets before they are live in production but also not artifically show chronic overcommitment.

Are there any ways people have found to account for this problem, this way or another way?

1 answer

1 vote
david bachowski August 19, 2015

We had a similar problem where we sent development tickets to QA after a sprint was complete. We set the ticket to 'Done' in JIRA agile on Code Complete but that ended up having its own issues for tracking post-sprint.

We are now doing QA within our sprints so that every ticket gets to 'Done' properly by the end of a sprint and it has been MUCH better. Plus we don't have to fight JIRA anymore and we actually have releasable software at the end of a sprint as Scrum would like us to.

Michael Redgrave May 15, 2017

Hi David,

We are currenlty having a similar issue where some of our QA work for a release is done after the sprint is complete, did you find a good workaround for this issue?

 

Regards Michael 

Suggest an answer

Log in or Sign up to answer