Documentation for GreenHopper 6.2.x. Documentation for earlier versions of GreenHopper is [available too].

(info) This page only applies to Scrum boards. If you are using a Kanban board, please see Releasing a Version (Kanban).

On the final day of the sprint the team will complete the sprint — this will usually occur immediately prior to the sprint demo and retrospective. Any issues not completed at the end of the sprint will be moved to the next planned sprint, as they did not meet the team's definition of "Done". If you do not have a next planned sprint, they will be returned to the backlog.

To end the active sprint,

  1. Login to JIRA.

  2. Click the Agile link's down-arrow in the top navigation bar, then select your preferred board from the resulting dropdown menu.

  3. Click Work.
  4. Click the dropdown next to the sprint name to display a dialog box (see Screenshot 1 below).
  5. If you wish, edit the Sprint Name, Start Date or End Date.
  6. Click the Complete Sprint button.
    (info) You will need to have the JIRA 'Project Administrator' permission in the project(s) whose issues are included in the sprint.
    (info) When you try to close a sprint, and you have parent issues not Done but all sub-tasks are Done, or visa-versa, you will be prompted to make the parent Done before continuing. For issues to be interpreted as 'Done' on your Scrum board their status needs to be mapped to that column, so if you're receiving errors for parents or sub-tasks that you believe are in fact Done, ensure that they are mapped correctly.
  7. You will be taken to the Sprint Report. Your issues will move out of Work mode. Any incomplete issues will move back into the backlog and will be visible in Plan mode.

Related pages:

 (info) Note:

  • Because Scrum teams usually track completed issues by version rather than by sprint, your issues will not be marked with the date the sprint was closed.
  • Once a sprint is closed, you cannot re-open it. If you need to view the contents of the sprint again, you can select that sprint in the Sprint Report.
  • You can find issues belonging to all closed sprints by using the closedSprints() function. For details, please see the JIRA JQL documentation.

Screenshot 1: Completing a Sprint

 

You can release the sprint as a version if you wish

Many Scrum teams don't release a version at the end of a sprint, but if you need to, it's easy to do. In the Completed Issues section of the Sprint Report, just click View in Issue Navigator. You can then use JIRA's Bulk Edit to assign all of the issues to the relevant version (for details, please see the JIRA documentation on

 Bulk Operations
). Note that you will not be able to do this if your "Done" column sets an issue's status to "Closed", as issues are not editable once they are "Closed" (but "Resolved" is fine). Also note you can only Bulk Edit the "Fix Version" for issues from one project at a time.

 

 

64 Comments

  1. Anonymous

    Someone one my team Closed the sprint rather than a story and now the Sprint has been closed prematurely.

    How can I re-open a Sprint? 

     

    1. Anonymous

      I have the same issue. Now way to recover a closed sprint?

      Can we have a lock not to close a sprint before an end date or so as a safety lock. So any premature closure can be reopened?

  2. Rosie Jameson [Atlassian]

    Sorry, a sprint can't currently be re-opened.

     

  3. Anonymous

    Thanks for letting me know.

  4. Anonymous

    Is there a way to delete a sprint we created as a test?

  5. Anonymous

    We just ended our first sprint (yay!) but it took me diving into help to figure out the little up-and-to-the-right arrow was the close sprint icon.  Perhaps there could be something on the plan mode screen that more intuitively lets you close a sprint in progress?  Or something more intuitive on work mode?  Or maybe just something on the top of the rapid board?  It just seemed a little confusing to find that little button. 

    Other than this minor nit, we love using Greenhopper! 

  6. Anonymous

    We accidentally closed a sprint with stories that were done but not in the done column.   Can I update those stories so that they reflect the fact that they were completed in that sprint?

    1. Anonymous

      +1

    2. Anonymous

      +100

    3. Anonymous

      +1000

    4. Georgi Mitov

      +1

      It should be possible to reopen a sprint. One might hit the Close button by accident - then what? There can be some constraints - e.g. not being able to reopen if another sprint has started...

    5. Laszlo Kremer

      +1 The very same happened to us, forgot to put the story into the done column (story swimlane is not very talkative about that). Right now I have no Idea how to put the story into the closed sprint. There should be a reopen.

    6. Anonymous

      +1

  7. Anonymous

    I'd like more information regarding Atlassian's rationale for treating sprints and versions separately. When a new bug report is received, the first question that I am going to ask is "In which sprint did we release it the affected feature?," which is synonymous with asking "In which point release did this go out?" Why not instruct Greenhopper to automatically update the fix version of tickets that get moved to the "Done" column within a Rapid Board?

  8. Anonymous

    Going to the sprint report, then clicking on to the issue navigator then clicking bulk edit and then having to use the terrible UI for bulk edit in JIRA is not what I would call a 'solution' to releasing a version when finishing a sprint.(thumbs down)

  9. Svein Are Grønsund

    This is how I experience things:

    • When ending a sprint, the issues are first closed by the users/tester (when they drag the issues to the last column)
      (Fix version is often forgotten by the user at this stage) 
    • Now when all/most issues are closes, admin wants to complete the sprint (clicking the "Complete sprint..." icon in Work-mode of the board).
    • The admin sees the Sprint-board and can now enter the bulk-change-mode for all the finished issues (set the fix version)
    • BUT WAIT, all these issues have been closed, thus it's not possible to change the fix version, admin first have to RE-OPEN all issues, change fix version and then re-CLOSE them again...

    We need a better solution to this... And a "best practice" description that is real..

    1. Svein Are Grønsund

      I now found an ok solution to this. This is what I did:

      • I installed a plugin "JIRA Suite Utilities" 
      • I modified the workflow so that the closing-transition required a "fix version" (this verification is a part of the mentioned plugin)
      • With this in place, dragging issues to the last column in Work-mode will close and ensure a "fix version"
      • No need for "bulk-action" after completing the sprint (smile)

    2. Anonymous

      That's a standard JIRA workflow you are using. It's not specific to GreenHopper. You need to modify it to Allow Edit issue in Closed state.

    3. Anonymous

      Another solution is to configure the board to remove the "Closed" status from the last column of the board, and so when developers, etc. move an issue to Done it is "Resolved" but not closed. Bulk edit will always work then, but the Admin will have to later close the issues.

      This gives the project lead/manager oversight of definitively closing an issue and can be accompanied by a change to permissions of only allowing an administrator, project lead or reporter to close an issue (but allowing developers to resolve one).

      1. Anonymous

        If you removed Closed from the Done column, then any issues that are legitimately closed during the sprint appear in your sprint report as Issues Not Completed.  We use Closed for release to production. However, we also close out issues for Spikes or issues where we determine, as part of getting into the details, that there is no need to do any work (it was WAD) or what we thought was the issue, isn't -thus we close the one out and create a new one for our backlog.

         

         

        1. Anonymous

          Can I have a custom status mapped to the "Done" column or does it always have to be "Closed" or "Resolved". Also the does closed/resolved refer to the status or to the resolution?

        2. Lisa Rahder

          When an issue is in its last status, i.e., "Done" or "Complete" or whatever has been identified as the last status in the workflow, it will not appear in the project backlog when that Sprint is marked as "Complete" by the scrum master.  But, this "Done" or "Complete" issue is not "Closed" unless explicitly designated as "Closed" by anyone with edit mode to that Issue (...once the Sprint is Completed you can always see this Issue from a filter). 

          Only when an Issue is designated as formally "Closed" will it be put permanently into Read mode, and so impossible to edit.  The status of the Sprint is not a factor.

  10. Anonymous

    I am an Admin user, but the cog by the sprint name does not render/appear for me.  I am not the Admin who created the sprint.  Is this a reason why I cannot close the open sprint?  Any insight/advice is appreciated.

    1. Anonymous

      To finish the active sprint: (click to expand)

      1. Select Work mode on your preferred board.
      2. Click the 'Close sprint' icon at the top of the 'Done' (rightmost) column.

      (I had the same problem .. further searching surfaced this in Greenhopper 101)

    2. Rosie Jameson [Atlassian]

      Can I ask which version of GreenHopper you are using? The "Close sprint" icon has recently been replaced by the "sprint" cog drop-down in GreenHopper 6.0.2.

  11. Anonymous

    We have been happily using Greenhopper for many iterations. We release at the end of each sprint. We just upgrade our JIRA and Greenhopper, and I'm very concerned about the new planning boards. If a sprint is not represented by a version, then where is it stored? How does one change the sprint that a single issue is assigned to, without having to always load the planning board? 

    None of my existing sprints map to the new sprints, does this mean I have to start configuring from scratch? How is it possible that once a sprint is closed it can't be reopened? At that point, are you supposed to create an entirely new sprint and move everything over? 

    We use versions to manage a bugs backlog and a feature backlog, and we pull from both into a sprint. How are you supposed to load different versions into the new interface? 

     

    1. Anonymous

      I agree. I can understand that you might want >= 1 sprint per release but the latest interface doesn't appear to tie sprints & releases together at all. I (very used to the now "Classic" boards) am finding this latest version significantly more complicated than it needed to be. Horrid. A complicated interface even more complicated.

       

  12. Anonymous

    I am running into an error when I try to close the sprint. On my Rapid Board, I get an error that certain JIRAs do not have sub-tasks complete or I don't have Admin privs on a project. But the JIRAs with incomplete subtasks or projects it is complaining about, are not part of the filter for my Rapid Board and do not show up anywhere. I am not sure why am I getting this error or how to fix it. Any help will be appreciated.

  13. Anonymous

    What is Greenhopper's definition of a "completed" issue?  I expect it to treat any issue that is 'Resolved' or 'Closed' as completed, as well as any story whose subtasks are all in the 'Resolved' and/or 'Closed' state.  However it does not seem to be doing this, as when I close a sprint it always tells me that all my issues are "incomplete" and will be returned to the backlog.  

    What's the magic procedure for "completing" an issue, and why doesn't Greenhopper understand that a resolved issue is "completed" and that a story with no incomplete subtasks is also "completed"?

    1. Anonymous

      +100000000

    2. Rosie Jameson [Atlassian]

      Please ensure that your rightmost column is mapped to the appropriate status(es). If it seems correct, can you please contact http://support.atlassian.com ?

  14. Anonymous

    Being able to map a sprint to a version is vey useful. Specially when most plugins, reports etc. will work on a 'per version' basis but you can't do it on a 'per sprint' basis.

    I would be also usefull to some teams mapping N sprints to a version or N versions to a sprint.

    But loose sprint/version relationship shouldn't be the std way to go as it is now. Very cumbersome and confusing. Std should be 1version=1sprint, and then you can customize otherwise if you want.

    Regards

  15. Anonymous

    I am not able to complete a sprint, eventhogh I am the adminitrator of the project.I am always getting the error like "administrator" access is required.

  16. Anonymous

    Bulk Edit is not an ideal solution to setting fix version. Bulk Edit overwrites all existing fix versions...you don't know what values you're overwriting!

  17. Ricardo Zuasti

    Hi, does anyone know what is the reason the "Release..." button is not present on Scrum boards? It would be really practical, since right now the project lead has to create the target versions in advance so developers can set the "Fix version" field when they resolve each issue.

    Maybe there is a methodological reason for it not being there... any enlightening?

     

    cheers,

    r.

  18. Anonymous

    How does the Sprint Report determine a closed issue?  Is it determined my the issue Status?

    Thanks!

    1. Anonymous

      Sorry, I meant a 'completed' issue.

      1. Rosie Jameson [Atlassian]

        For issues to be interpreted as 'Done' on your Scrum board their status needs to be mapped to that column, so if you're receiving errors for parents or sub-tasks that you believe are in fact Done, can you please check that they are mapped correctly?

  19. Anonymous

    I read above:

    'Any issues not completed at the end of the sprint will be returned to the top of the backlog'.

    I have just completed a sprint, but such issues were immediately moved to the new sprint, not to the backlog.

    Please clarify.

    1. Rosie Jameson [Atlassian]

      I have updated the documentation as follows: Any issues not completed at the end of the sprint will be returned to the backlog (or to the next planned sprint, if you have one)"

      Many thanks

      1. Anonymous

        Great, thanks for that agile documentation update!

        Of course, it is a good feature.

      2. Todd Stephan

        What do you mean by "or" how will it decide which to perform?  I created a new sprint but when I go to close the current sprint it still says it will move not-done items to the backlog.  If I have three sprints created and in various stage of planning, what is considered "the next sprint".  You can't add dates to the sprint until it is started.

        1. Andrew

          Hi Todd,

          • "What do you mean by "or" how will it decide which to perform?"— GreenHopper should move issues to the next planned sprint in preference to the backlog. I'll update the wording.
          • "If I have three sprints created and in various stage of planning, what is considered "the next sprint"" — Each sprint is added sequentially when you create it, i.e. Sprint 1, then Sprint 2, then Sprint 3, etc, even if you rename the sprints. If you complete Sprint 1 with incomplete issues, they will be moved to Sprint 2.

          Kind Regards,
          Andrew

          1. Todd Stephan

            Thank you for the quick response!  I have one more question.  I have create a "next" sprint which is ready to be started once the current open sprint is marked as completed.  When I open the complete sprint dialog, it says the incomplete issues and partially complete issues will be moved to the top of the backlog - even though I have a next sprint all setup in plan mode.  Is the dialog just not specific enough?  I don't want to complete the sprint without knowing what it is going to actually do.

            Thanks!

            1. Todd Stephan

              I went ahead and selected complete and it did indeed move my items into the next sprint despite the dialog stating it was going to move them into the backlog.  The text should reflect the activity it is going to perform.   Thanks.

  20. Anonymous

    I really miss the closed sprints in the planning view. I would like to see the entire project, complete with history. It's akward to have to go into the history to see the sprint i closed last week. Would it be possible to add a filter instead, so that the user can chose if the completed sprints should be visible?

  21. Daisy Pilbrow

    So what happens if you have epics in your sprint? This statement does not seem to apply in that case: "Any issues not completed at the end of the sprint will be returned to the backlog (or to the next planned sprint, if you have one)".

    We had uncompleted epics at the end of a sprint and clicking the "complete sprint" button did not move them to the backlog. Instead, they completely disappeared from the planning screen. I had to batch edit the epics and change their Sprint in order to get them to show up again. A really unfortunate side effect of the batch edit was that all the "Done" issues in the epics now appear in our work board again...

    Clearly I am doing something wrong here. Any suggestions.

    1. Rosie Jameson [Atlassian]

      Hi Daisy, I'm not sure if you are using our latest implementation of Epics. Can you please contact http://support.atlassian.com ?

      1. Anonymous

        Hi Rosie, I have had the same problem.  I just closed my first iteration, and all stories moved over as expected, however, the Epic did not.  Any suggestions?

  22. Anonymous

    Argh, so close to doing what I wanted and then you pulled the rug out from under GreenHopper!

    The lack of mapping between Releases and Sprints like in the old 'Classic' GreenHopper system is a real shame, it seems Atlassian gives with one hand and takes with the other, every time I see the next version of JIRA/GreenHopper I think "Great I can finally retire my MS Project plan and Excel spreadsheet", then realise that whilst adding a feature I needed they've removed an existing one! Using Scrum is not a reason to abandon all planning activities beyond 2 sprints into the future, some of us do actually need to plan releases and communicate expectations to stakeholders, even if all the future releases contain are Epics.

    I have a simple MS Project plan that lists 4 releases for 2013 (~3 months each) with around 5 sprints in each release with hardening time and a release sprint etc. This simple structure cannot be easily represented in the latest GreenHopper (but could in the old version). In addition the separation of Epics and Stories in the new version makes planning very hard, it isn't possible to assign an Epic to a 'Release' (e.g. to be split and planned into a sprint) like in the old version. Like I said, using Scrum isn't mutually exclusive with doing some forward planning. The stakeholders want to know how many sprints there are in the current Release and the likely functionality we will be adding by the end of the Release and some overview of at least the next Release if not 2 into the future, after all they are actually putting up the money for the project and want to know what they are paying for!

    In conclusion, please add support for grouping Sprints into Releases and assigning Epics to Release like in the old GreenHopper.

     

    1. Rosie Jameson [Atlassian]

      This is something we plan to address. Please see GHS-6588 - Getting issue details... STATUS

  23. Anonymous

    It seems that the boards have not been developed to allow for any mistakes or possible variation.  If someone makes a mistake (e.g. accidentally closes a sprint, cannot start a sprint with the correct date if someone was not available, with the correct permissions, to start it, input the wrong story points, etc.) Since you have to administer the project to be able to do most of this,please allow these individuals to do their job and have accurate reports.

    You can go to JIRA and edit story points and the assigned sprint, but then those are not reflected.

    Mistakes or people not being available, do happen.

  24. Daniel Eichling

    I would like to inquire about the possibility of being able to assign sprint start/complete privileges to people in roles OTHER than project administrator

    In my company, and I'm sure in others - we use JIRA to help track a central bug repository that is worked on by many teams. For many reasons, we can't have all our PMs assigned as project administrators for the bug project, which means using the boards to start and close sprints that include shared bug tickets falls to a few JIRA admins that have universal admin rights.  This could be solved very easily by allowing us to assign this permission like any other permission in JIRA, so that another role could share this responsibility.  The only other solution to this is to clone a massive amount of tickets, which is what we wanted to avoid by moving to the new boards in the first place!

    1. Rosie Jameson [Atlassian]

      Hi Daniel, you may like to watch/vote/comment on GHS-5242 - Getting issue details... STATUS

      1. Daniel Eichling

        Thanks for the heads up. Commented and voted!

  25. Elin Throsteinsdottir

    Hi

    Im experiencing the same problem as has been mentioned here earlier; when I close a sprint it always tells me that all my issues are "incomplete" and will be returned to the backlog, despite the fact that they are all in "done" and I have closed them.

     erer

  26. Anonymous

    I am trying to close a Sprint, however I get the following error: To update this sprint you must have Project Administrator permissions for all of the following projects: X and Y.

    This is a agile board for 'project = X " ORDER BY Rank ASC'

    Project Y should not cross over to project X at all.

    Any ideas?

    1. Rosie Jameson [Atlassian]

      Can you please contact http://support.atlassian.com ? Many thanks

    2. user-bee43

      we've met the same case. the cause for our problem is.

      we have an issue e.g. X-123, which used to belong to project X, and at that time, we added into the sprint, and then we move this issue from project X to project Y.

      When we try to close the sprint in project X. because the issue X-123(now, the key may be changed to Y-456) belong to the sprint, and also belong to project Y, and the owner of the agile board don't have permission in project Y. then the owner of the agile board failed to close the sprint, the error messages says that "he needs the administration permission for both project X and Y"

      1. Dustin Chesterman

        Any known fix for this?

        1. Oliver Powell

          +1

          I have this problem as well (version v5.2.7). I had a JIRA moved into my sprint from another project and I now cannot complete the sprint because I'm not an administrator in that project (and I shouldn't be). I am of course an administrator of my sprint, and have been able to close all previous sprints.

          Also, I've hunted through all Jiras in the sprint to find ones that were moved from the other project (not an easy thing to do, have to look thru history). Found only one, removed it from the sprint, but I still cannot complete the sprint!  So I'm stuck...

          Or am I doing something wrong?

          Any help appreciated thanks (smile)

  27. boardtc

    Having inherited a project I have found an open issue which is in a closed sprint, it must have got pulled in by mistake, not having a way to remove it from this closed sprint is very unfortunate. Also the issue can't be cloned due to this bug.

  28. Christian Czaia

    Any issues not completed at the end of the sprint will be returned to the backlog (or to the next planned sprint, if you have one)


    Is there a way I can force the stories to be returned to the backlog? Automatically adding them to the next sprint ist just not the way this should be...

    Corresponding question on Answers:

    https://answers.atlassian.com/questions/172797/incomplete-stories-to-backlog-instead-of-next-planned-sprint

  29. Pavel Dovhomilja

    Problem during transfering not closed issues to new sprint.

    When I am closing old sprint I want to transfer not completed issues to new sprint but sometimes everything return to backlong (not every time). 

    Why is this happening? Some criterias has to be fulfilled? 

    Thank you a lot.



Log a request with our support team.



Raise an issue for our developers.



See answers from the community.



Tweet, blog and update our documentation.

Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 2.5 Australia License.