November 25th, 2015 by Adam Sandman
We often think of a release as a simple idea, you have a new version (say 1.0) of a product and you plan on releasing it on a specific date. You might then divide up that release into either iterations or sprints if you're using an agile approach or perhaps phases if using a waterfall one. You then want to be able to report at the project, release and iteration level. Well after much feedback from customers, we found that customers need more than that...
Releases contain Releases
Sometimes you have a major release that actually consists of some smaller versions that ultimately part of the same release. So you really want to be able to report on the top-level release as well as the child releases and any iterations that are part of either release. So it sounds like you need to have reporting that aggregates up across multiple levels of releases. For example a development task that is late in one iteration will now affect the minor release and the major release at the same time. Similarly a test case may fail in an iteration that affects both the overall release and the smaller minor release.
Not all Releases are Equal
So does that mean we always need to include child releases' information when determining the task progress and the testing status of a release? Well unfortunately not always. The converse case is when you have a major release (say 1.0 again) and after it's done you now release a new version 1.1 that is part of the v1.0 branch but its' failings and progress are separate from the already shipped version 1.0. This is where one of the new features in our next Spira 5.0 version comes in.
Spira 5.0 Releases
In the upcoming release of SpiraTeam we have added the concept of release statuses and release types. These replace the old Iteration = True/False flag and the Active = True/False flag. Releases can now be one of four types:
- Major Release
- Minor Release
- Iteration / Sprint
- Phase
The split between iteration and phase lets you keep certain "iterations" out of the Scrum planning boards. This is useful when you have a hybrid agile/waterfall project that will have true agile iterations and also some waterfall phases (such as user acceptance testing or integration).
More importantly, this allows you to have releases that do pass on their testing status and development progress information up to their parent release and releases that don't. This flexibility gives you the best of both worlds.
In addition, we have implemented workflow capabilities to releases so that you can track and manage releases in different statues:
- Planned
- In Progress
- Deferred
- Cancelled
- Completed
- Closed
This lets you define a release management process that works for you, complete with customizable transitions and permissions:
For those of you already using SpiraTeam, these workflow capabilities are similar to the ones we already have for requirements, tasks and incidents.
These screenshots also include a preview of the new Spira 5.0 responsive UI that has been made possible thanks to use of the Bootstrap UI framework.