Should I close a sprint when we do not have a QA/STAGING/PROD environment?
Usually a sprint shall be closed when the stories have been finished and released to DEV, QA, STAGING, PROD env. But as our project just start, we only have DEV. When the sprint end, can I close the sprint in Jira and reopen them in the future when other environments are ready? Or should I keep the sprint open until tester and project manager have reviewed and accepted the stories in QA/STAGING/PROD env?
The Scrum Guide says:
"The heart of Scrum is a Sprint, a time-box of one month or less during which a 'Done' useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint."
How important do you think it is for your team to observe:
- a release-quality Definition of Done, and
- the rules of Sprint time-boxing?
Next to Ian's excellent questions, what effect does this have on transperency if you "close" tickets that are undone?
How can you inspect&adapt on this?
If you have to wait long time for QA/STAGING/PROD environment, in that case, I would say that Sprint can be closed.
But you should most likely adapt your Definition Of Done to reflect the current reality. And make sure that you have an agreement on Definition Of Done from the stakeholders mainly PO and Development team.
Speaking specifically about Jira, there's a difference between closing a Sprint and closing/resolving/completing issues.
If you are following Scrum, you should close the Sprint at the end of the Sprint timebox. Personally, I encourage my teams to close the Sprint at the start of either the Sprint Review or the Sprint Retrospective. Closing the Sprint will allow Jira to compute metrics, such as what issues were complete, what issues were incomplete, generate burndown charts and other reports, and allow you to move the undone issues somewhere else.
Your Jira workflow should match up with your development process. Issues should be in a done state with a resolution after they meet your team's Definition of Done. This is important for Jira to understand the difference between completed and incomplete work, and some things trigger off of an issue having a resolution while other things trigger off of the state of the issue. If you are using boards, you also need to make sure that the states of all issues and sub-task issues are mapped to the board.
Personally, I do not promote the idea of closing and reopening issues. Issues should be closed once the work is done. If something was left undone, opening new work and linking it to the existing work is a good choice. You can even use issue types to track different kinds of work (new features/functionality, technical debt, bugs, etc). The linking capability lets you identify blocking issues, related work, and so on in a human readable way. Some plugins can also take advantage of linked issues.
If the lack of prepared environments are keeping you from completing the work according to your Definition of Done, this will become apparent in the reports that Jira can generate. Having these reports and undone work in Jira can help focus discussions during your Sprint Retrospective.