As a Scrum Master using JIRA allows you to have only one active sprint at a time with Scrum. After all, this is how it is suppose to work as sprints are very short lived. However, remember when you had one of those crazy development projects that had a nearly impossible time frame to achieve? Or, you had an Agile project with multiple teams, and you wished each team could have their work handled as a separate sprint running concurrent with another sprint? Perhaps you are one of those projects right now. For Scrum Masters in these situations looking for more throughput and options, a “parallel sprint” feature was introduced into JIRA.
The parallel sprint feature originated in the Atlassian JIRA Labs for JIRA around 2014 and remained in beta for about eighteen months. Beta was fairly easy to get access if you had a SaaS cloud version of JIRA Agile (recently re-branded the name to JIRA Software). However, it was during the release of JIRA 7.1 this feature came out of the lab closet and became part of production JIRA. A parallel sprint is sometimes referred to as a concurrent sprint. It is pretty handy for not only stupidly aggressive deadlines, but just simply managing multiple teams on sprints with unrelated epics and stories. Over the past year, I had the opportunity to run a couple of Agile projects with JIRA's parallel sprint feature in beta (the production feature is no different). The outcomes were successful and the team fully embraced the notion of doing parallel sprints. This particularly came in handy for ecommerce projects where backiend development tasks and separate UI design/development tasks were occurring at the same time.
At this point, I should tip the hat to those of you from the more purists angle, or academia side of Agile. Yes, the notion of multiple sprints running concurrently in parallel goes slightly against the core philosophy of the Agile lifecycle. With Agile, the workflow is more serialized as the team works on just one active sprint at a time, and then moves onto the next sprint once the current one is delivered. It works extremely well as the releases are happening every two or three weeks on average. The use parallel sprinting is more conditional versus the standard operating of Scrum. It is still best to keep with standard practice of serialized sprint delivery. The parallel sprint is an optional tool in the arsenal.
What does a parallel sprint look like in JIRA?
Check out the diagram below. This is a screenshot of a JIRA project in flight. You will notice there are two sprints active: Sprint 1 and Sprint 1a.
Each one has their cumulative story point totals active. Additionally, each one has their burndown occurring as the work is be completed. These two parallel sprints can have their own names and delivery dates as well. In fact, there is no dependency in JIRA on sprints 1 and 1a. Just like a single sprint, it is still up to the Scrum Master to coordinate the two releases.
FIVE TIPS on using parallel sprints in JIRA
There are some tips one can consider when doing parallel sprints in JIRA. These are the most predominate ones:
1. Limit Your Concurrencies – Although JIRA will allow you to have as many parallel sprints as you desire, it can become risky going beyond two or three concurrences if there are significant story points in play. As a rule of thumb, the more parallel sprints that are active, the less story points that should assigned in each sprint. Again, the idea is to minimize risk of over extending the scrum commitments. You do not want to end up with a circus act of many plates on spinning on sticks.
2. Multiple Daily Stand-ups - It can be helpful to have separate daily stand-ups for each active sprint. Combining the two or three into one scrum can prove to be tedious from a communication perspective.
3. Sprint Release Dates – In terms of release, it can be easier to have the parallel sprints timed (or synchronized) to release at similar dates. They do not have to end on the exact date together, but certainly within days of each other. This helps from a deployment perspective as the release can be coupled together for production and approvals.
4. Story Point Balancing – There is some advantage in having parallel sprints contain a similar amount of story points. It helps give some synchronization in the velocity between the active sprints.
5. Communication – As you do your multi-daily stand-ups, be sure the separate stand-ups have some awareness of the progress of the two sprints. This helps in synchronizing delivery and potentially identifies any potential dependencies that could be blockers.
Finally, once you have completed the parallel sprints, be sure to close them out like any other sprint.
---------------------------------------------------------------
About The Author:
Brad Beiermann is a nationally recognized technology executive, author, and speaker with specialization in e-commerce, Agile, mobile, and start-ups such as Cimstrat.com, ProfessorString.com, HienoteDirectory.com, and others. He has considerable experience as a digital technology management consultant with Fortune 500 companies and the entrepreneurial community. He can be reached at bradb at cimstrat dot com.
