Streamlining Multi-Platform Development Workflows with Jira

I’ve been assigned a very exciting challenge to build and map the process & workflow on Jira for a 5.5Million $ in revenue to streamline their development life cycle and completed the challenge successfully! to manage the software development life cycle for a SAAS supported across iOS, Android, and web platforms. Here’s a detailed breakdown of the journey and the innovative solutions we implemented..

Challenges with the Old Workflow:

Duplicate User Stories: User stories were duplicated across different Jira projects for the same SAAS product, despite having the same set of features and product roadmap for all three platforms. This duplication led to issues with product documentation and made it difficult to maintain the user stories every time one line needed updating, it had to be done at least 3 times..

Inconsistent Feature Behavior: Maintaining the same user story three times resulted in inconsistent behavior of features across platforms since release dates didn’t necessarily have to be the same, as a feature can be supported on web until it has been released for the mobile apps..

Tracking Releases: It was challenging to keep track of which features were pushed on which platform. The product team often had to compare and cross-check feature releases by testing the app so that the backlog is updated to plan sprints properly for each platform independently..

The New Workflow Solution:

To resolve these issues, we enhanced our workflow by creating a unified Jira project where user stories are shared across different boards. This allows user stories to be maintained once and recycled into different sprints and development phases independently for iOS, Android, and web. This prevents user stories from moving to “done” too early or disappearing from the backlog prematurely.

Key Features Used From Jira To Create The New Workflow:

1. Components: We created a component for each platform, allowing user stories to be tagged appropriately. This ensures that multiple product owners can manage the project while keeping user stories consistent.

2. Customized Boards: Boards now visualize different items from the backlog based on components & filters, ensuring the right teams see the right stories on the right time, aligning better the release dates and product roadmap.

3. Custom Workflows: We customized workflows for different issue types to align with our development stages and definition of done. This allows the user story, and different issues to move within different boards without prematurely moving them to DONE.. This allowed to run sprints smoother without having the issues remain on the same sprint board until they have been released or taken outside from the sprint..

4. Custom Issue Types: Different issue types help manage the workflow better. For instance, design tickets don’t need to pass through the entire development statuses like code review, can be handled separately with a different workflow

5. Custom Filters: Filters help keep relevant context on the relevant board, enhancing visibility for the right team, especially when teams are divided into multiple squads.

6. Manual Fields Configuration: We added manual fields for designers, business analysts, QA, and impacted areas to improve ticket handling and workflow visualization that fits the scrum team and they way the communicate through the ticket.

7. Issue Layout Customization: By customizing issue layouts, we reduced unnecessary fields and added valuable ones specific to each issue type, improving focus and efficiency.

8. Automations: Of course automations come in hand to have the workflow run more seamlessly, like automating the creation of sub-tasks, auto-assignments, and auto-updating components based on issue types, labels, or sub-task summary field value..

New Workflow Challenges and Resolutions:

1. Sprint Management: Since user stories planned across all teams can’t belong to two sprints simultaneously, we implemented manual custom fields for the mobile sprint value and regularly updated filter criteria to manage sprint cycles, as the mobile sprints were planned independently unless it was a user story that had to be planned with all of the teams together for a combined release across all platforms..

2. Reporting: Standard Jira sprint reports were inadequate for our needs, so we created custom dashboards to measure sprint capacity and achievements, ensuring accurate reporting for multi-platform releases.

Collaboration and Continuous Improvement:

Building this complex workflow was a collaborative effort with our scrum teams. It involved continuous testing and refinement to ensure all teams were comfortable with the implementation and visualization. It wasn’t a one-time effort but a continuous trial and error process to perfect the workflow for a complex project with multiple teams.

This has been the best challenge I’ve had in quite a while, and I’m proud to have completed it in short time with minimal interruption to our development cycles..

Leave a comment