Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Sprint complete and release tracking

Shwetha.Peruri
Contributor
September 7, 2020

Hi,

We are currently maintaining a scrum board where Done is the the last column(right most)in the board and we set the stories to done after its released to production.

If there is any closed stories or invalid defects we move them to done status and set the resolution as "Invalid" or "Wont fix".

We do weekly releases, but at times due to some unavoidable reasons, the release date gets moved by a day or two but the next sprint starts immediately after a week.

In this case there will be two active sprints at a time since I will not be able to complete a sprint unless the production release for the first sprint is complete. 

Is this a good practice? If its not, How can this be avoided? Do you suggest moving the stories to done as soon the development and testing is done? If this is the case how do I track if a particular story is released? Is there any specific field that can be set once the fix version is set to Released?

2 answers

1 accepted

1 vote
Answer accepted
Ste Wright
Community Champion
September 7, 2020

Hi @Shwetha.Peruri 

A sprint is a timebox - if the timebox ends on a Friday, it should be completed (even if no release has taken place). Keeping it open makes the benefit of the timebox less valuable.

--------------

With releases, I find it depends on your team's definition of done:

  • Completed: If your DoD is the story is completed (developed, tested, etc) - but not released into production - I would be closing the stories as "Done" at this stage. Whilst it would be ideal to release to production every sprint, it might not always be possible for all companies.
  • Released: If your DoD is the story is released to production, I would keep those stories open but close the sprint - and move the stories to the next sprint. I would then retrospect why the release was moved back a day or two. For example:
    • If the release was moved to allow for more stories to be complete, was the sprint too full? Was the release too large?
    • If the release was moved due to environment issues, how can we improve next sprint to avoid the same issue repeating?

--------------

In the Completed option, you could manage releases via the Release Hub.

In terms of locating whether a Story is released, you could use JQL for this:

project = ABC and issuetype = Story and fixVersion in releasedVersions()

...or if you need a visual representation of the release on the Story, you could create a...

  • Custom Field: To visualise when a Story has been released - for example:
    • A Select List (single choice)
    • Call the field "Released" - give it two values (Yes/No), and default the value to No.
    • Put the field just on the View Screen - so it isn't easy to edit manually
  • Status: Have two "completion" statuses:
    • For example - "Done" for completion in the sprint, and "Released" for released to Production
    • Have both in the final column on the Scrum board - so both are counted as "Done" from a sprint perspective

You could then use an Automation Rule to automate the custom field changing to "Yes" - or the status transitioning to "Released" - for all issues in each version, when they are released!

--------------

If you'd like help to create one of the options above, let me know and I'd be happy to provide instructions :)

Ste

Shwetha.Peruri
Contributor
September 7, 2020

Thank you so much. You read my mind :)

I will definitely propose the above solution to the management and I will set up accordingly in JIRA.

I think option of having a custom field and setting to Yes works better. In either case , what do you suggest for issues that were already released to production. Shall I do a bulk update to set the custom field Released to Yes?

Like Ste Wright likes this
Ste Wright
Community Champion
September 7, 2020

Hi @Shwetha.Peruri 

Awesome!

I would do the bulk update.

That means if you want to create reports or filters based on the field, the data will be consistent - rather than being a "new" process from today.

Ste

Rakesh
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
September 24, 2024

A followup question: how do you calculate the team's acceptance ratio (say-do ratio) & velocity in this case. Do we give the team credit for the userstories which were marked "Done"? Or we wait until it is "Released"?

If we dont consider Done as complete. then
Sprint 1: say-do ratio will be 0
Sprint 2: say-do ratio will be <sum of storypoints of all US marked as Released>

Thoughts?

0 votes
Rakesh
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
September 24, 2024

___

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events