After the research, here is the info. Hope it helps somebody. Apparently sprints are not related to projects at all, rather to boards (for what reason?). they are simply a body of work that the team commits to. And boards although they live on projects, they are simply a way to visualize and filter issues. Boards can encompass multiple projects So I can start sprints on any board, with issues in it from any project. And by default there can only be one sprint per board, unless configured as a parallel sprint. Now, when we release, we release per project, releases are specific to for example software, or product. But sprints are not related to releases. In order for issues to be part of the release they have to be added to the fix-version (per project/product) either during the planning or later in bulk change. Once the sprint is finished, the issues are no longer visible on the board of active sprints. So better to make sure issues are added to the version/release prior to finishing the sprint. Which makes sense because if you use versions, you plan ahead of the time what will go into it.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.