I’m having trouble figuring out how to handle both sprint tracking and release planning in Jira when using agile boards. The agile plugin uses the “fix version” field to track which sprint an issue belongs to, but this creates problems when you also need to track actual product releases.
The main issue is that our team works on multiple products during the same sprint. For example, we might be working on “Product A version 2.1.0” (new features), “Product A version 2.0.3” (bug fixes), and “Product B version 1.5” all in the same two-week sprint.
Since the fix version field can only have one value, I can’t properly track both the sprint and the actual release version. Some solutions I’ve considered:
- Making sprint versions as sub-versions under release versions
- Using a custom field for either sprints or releases
- Creating separate sprints for each product (but this defeats the purpose of sprint planning)
Has anyone else run into this problem? How do you manage sprint planning when your team works on multiple products with different release schedules? I’m looking for practical solutions that don’t make sprint management too complicated.
In a similar scenario, we adopted a hybrid model that worked effectively at my previous company. We maintained the fix version field strictly for actual release versions and utilized components to distinguish between products. Additionally, we created a custom field named ‘Sprint Assignment’ for tracking which sprint an issue belongs to.
This approach emphasized the difference between sprints as time-bound activities and releases as deliverables, necessitating distinct tracking methods. By configuring our agile board filters to focus on sprint assignment, we achieved clear sprint visibility while ensuring accurate release tracking. This setup allowed us to produce release notes and monitor progress for specific product versions seamlessly, with the fix version field remaining intact for reporting, while sprint metrics like velocity and burndown maintained correctness with the custom field. Though it required some extra maintenance, the clarity gained in sprint and release management was invaluable.
We faced this exact challenge at my organization and ended up restructuring our approach entirely. Instead of trying to force the fix version field to serve dual purposes, we established product-specific release branches in our workflow and used labels for sprint identification. Each product maintains its own version numbering through dedicated fix version hierarchies, while sprint tracking happens through a standardized labeling convention like ‘Sprint-2024-01’ across all products. The key insight was recognizing that sprint planning and release management operate on different timelines and serve different stakeholders. Our product owners focus on release versions for roadmap planning, while the development team uses sprint labels for velocity tracking and burndown charts. We configured separate board filters for each view - one filtered by sprint labels for daily standups, another by fix versions for release planning. This separation eliminated the confusion around mixed contexts and made reporting much cleaner. Release notes generate correctly from fix versions, and sprint metrics remain accurate through consistent labeling. The initial setup took some effort, but the operational clarity was worth it.