Connect Now
The product follows a sprint-based delivery process involving Product Managers, QA teams, frontend/backend engineers, architects, and technical leads.
As part of my day-to-day responsibilities working closely with engineering and product teams, I regularly participated in sprint planning, delivery coordination, and cross-functional discussions aimed at improving sprint execution.
Several recurring problems started affecting sprint delivery and planning:
For example, it was common to discover that too many tickets were planned for delivery on the same day, making timelines unrealistic and increasing delivery pressure late in the sprint.
This also affected:
The problems became visible through recurring sprint patterns and day-to-day coordination work.
Some common situations included:
I discussed these issues with PMs, Scrum Masters, QA, and technical leads. Everyone viewed the problem from slightly different angles, but the common feedback was the same: delivery tracking and sprint planning lacked clear visibility.
Over time, it became clear that the issue was not the sprint process itself. The bigger problem was that teams did not have a simple way to visualise delivery timelines and planning gaps early.
Before changing sprint processes or introducing new tools, I first wanted to see whether the problem could be solved using the systems already being used daily.
Since Jira already acted as the single source of truth for sprint execution, I focused on improving visibility on top of existing workflows instead of adding more process overhead.
| Option | Why not chosen? |
|---|---|
| Add more coordination meetings | Increased manual effort without improving visibility |
| Use external tracking spreadsheets | Difficult to maintain and easy to fall out of sync |
| Introduce another delivery tool | Added unnecessary complexity |
| Improve visibility using existing Jira workflows | Chosen approach because it improved planning without changing existing processes |
The goal was simple: make sprint delivery easier to track, easier to plan, and easier to coordinate.
Built a Jira dashboard using JQL filters and calendar widgets to visualise:
This made it easier to identify unrealistic delivery clustering early in the sprint.
Created issue view to identify sprint tickets that were missing due dates.
This helped:
Created issue view to identify sprint tickets without story point estimates.
This helped teams:
Used the dashboards during coordination discussions with PMs, Scrum Masters, QA, and Technical Leads.
This helped identify:
earlier in the sprint cycle.
The Jira dashboard made sprint planning and delivery tracking easier to manage.
Key outcomes included:
The dashboards helped teams identify delivery risks earlier instead of reacting during the final stages of the sprint.
Better delivery decisions start with better visibility. By making sprint risks easier to identify early, teams could plan more realistically, coordinate more effectively, and reduce last-minute delivery surprises without introducing additional process overhead.
This initiative taught me that many delivery problems are actually visibility problems.
Teams were already putting in the effort, but without clear visibility into timelines, planning gaps, and delivery distribution, coordination became reactive instead of proactive.
I also learned that small workflow improvements inside existing systems can significantly improve delivery planning and team coordination without needing large process changes or additional tools.
