How to Stop Wasting Sprint Planning on Manual Status Updates
Do your sprint planning meetings feel more like a crime scene investigation than an alignment session? When you’re spending the first half of your meeting reconstructing what happened last sprint and stitching together context for new requests, the actual “planning” portion doesn’t get much time. That means you’re rushing through what should be the most important part of your sprint planning meeting.
Engineering and product typically use different project management tools, which rarely integrate natively. Context is manually stitched together, reviews cycle through multiple systems, and last-minute updates derail your planning.
That’s why you need integrations that automatically sync status updates.
The cost of manual status updates
Product teams typically work in project management tools like Asana or ClickUp while engineering works in dedicated tools like Jira, GitHub, or Azure DevOps. Each tool has all the context a team needs for their day-to-day work. But when teams come together, like during a sprint planning session, the gap between these tools is felt the most.
In this kind of environment, even a simple status update doesn’t carry over, potentially creating manual work that scales rapidly as you work. Say, for example, that the engineering team in Jira updates a specific ticket from “In Progress” to “Blocked,” because a specific module in your product isn’t working right, preventing them from making progress. The Jira work item lists the module, the affected version, and links to the item tracking what’s needed to unblock it.
Come sprint planning time, all that extra context is completely missing. The original work item might still show as “In Progress,” until someone from engineering mentions it’s blocked. Then they have to repeat why it’s blocked, how it can get unblocked, and how much work needs to happen to make it so.
Now imagine having to go through that same context with every item on your backlog, when someone’s already written it out in at least one of your systems. Before an item can be added to your sprint, you have to review every field in it to ensure it’s valid, usually against at least one other system.
How software teams can improve sprint planning sessions
Whether it’s changing the way you work across teams or the way you use multiple systems, here are some ways software teams can improve sprint planning sessions.
Before the meeting
- Use a two-way sync solution like Unito to integrate product and engineering tools, so context is always where you need it.
- Refine product backlogs ahead of time so you’re not sorting through irrelevant work items during the meeting.
- Use past sprint data and burndown charts to make future commitments more realistic.
During the meeting
- Timebox the meeting deliberately. Best practice is to plan for about two hours per week in your sprint.
- Focus on an outcome rather than a task list. The objective is less to have a stack of work to dispatch and more to make full use of capacity and focus on specific goals.
- Get everyone involved. Too many sprint plannings end up being team leads speaking among themselves, missing out on essential context from other collaborators.
After the meeting
- Run a retrospective every time you finish a sprint. Product managers and team leads should look back on a sprint and gauge how effectively they estimated capacity and handled unexpected work.
- Document and circulate your plan as soon as possible. Whether it’s in a project management tool or dedicated documentation, anyone involved should be able to quickly access your plan.
- Feed rollover back into capacity planning. When you go beyond your team’s capacity, track how much you went over and account for this in future sprint planning sessions.
What changes when status updates are synced automatically
Most product and engineering teams don’t sync status updates and other changes between systems at all. Usually, a project manager or team lead has to manually copy and paste data back and forth or get updates from engineers involved in that work. That’s where a two-way sync platform like Unito comes in.
Unito has some of the deepest two-way integrations for product and engineering tools like Jira, Asana, GitHub, Azure DevOps, and Wrike. It pairs work items across tools in real-time, meaning any changes made in one tool will be synced automatically to the other. That includes everything from status updates to comments and even attachments.
When you use a platform like Unito to integrate product and engineering tools, you get the first half of each sprint planning session back, as you can trust that every work item in your backlog has full context from your entire tool stack.
Coveo, a search and relevance company, uses Unito to bridge the gap between Asana and Jira, eliminating the constant copying and pasting a single project manager had to take on. The team at Coveo saves over 2,000 hours a year, leading to $218,000 in yearly savings.
Unsilo, an artificial intelligence and machine learning company, also uses Unito to close the gap between product and engineering teams. By integrating Trello boards throughout the company, they’ve saved 780 hours a year, leading to $72,000 in yearly savings.
Topl, a company building blockchain solutions to verify sustainable practices, integrates Jira and GitHub with Unito to improve collaboration between software developers and project managers. The team at Topl saves 624 hours a year and $57,000 in tool budget and productivity gains.
Why anything less than a two-way sync won’t work
Most software teams already use workflow automation tools that empower one-way automation across hundreds, if not thousands, of systems. These tools automate simple actions, like creating work items or updating a single field. They’re great tools for handling migrations and linear workflows, but they struggle to empower the kind of cross-functional collaboration required for sprint planning sessions.
Here’s why.
Imagine that you’re using one-way automations to push data from Jira to Asana. By default, a single comment in Jira explaining why a work item is blocked is pushed to Asana, so product managers are aware of the issue. But that’s where the automation ends. Any questions the product managers ask aren’t sent back to Jira unless you have a completely different automation to manage it. Similarly, a work item moving from one status to another in Jira isn’t represented in Asana.
A two-way sync automatically moves comments back and forth, updates fields and statuses, and syncs attachments across. All with a single flow. Replicating that with one-way automations would take a dozen automations, adding unnecessary maintenance and risk.
What your sprint planning session looks like with synced status updates
At least 30 minutes of your meeting back. That’s what you get when you use a tool like Unito to sync status updates between product and engineering tools. No more reconstructing everything that happened last sprint; you have a feed of every update in every tool you use. Your teams already know what’s blocked, what’s been done, and what’s been de-prioritized.
Your planning session actually starts with planning future work rather than reviewing previous tasks. You get a full session for prioritizing product work, breaking up complex work into smaller tasks, and getting a real sense of capacity from your engineers.
Say your product team uses Asana while engineering uses Jira. Typically, PMs and team leads have to jump back and forth between these tools to get full context on the product work coming down the pipe. But with a tool like Unito, a “Blocked” status in Jira maps automatically to a “Blocked” section in Asana. Comments from engineers describing why work items are blocked also get synced from Jira to Asana. That means product managers can have conversations with engineers asynchronously, where they need to happen, without switching tools. And, just by looking at their Asana projects, product managers know everything that’s blocked and why it’s blocked.
How a faster sprint planning session impacts your workflows
Here’s how a faster sprint planning session impacts your software development and product management workflows.
The impact on software development workflows
- Deeper planning sessions: Because you’re not constantly switching from tool to tool, everyone in a planning session can dedicate more time and energy to every backlog item, leading to better innovation and problem-solving.
- Stronger commitments: When you don’t have to spend half of your planning sessions reviewing past work, you have more time to spend on setting realistic scopes, which leads to greater commitment from your developers.
- More accurate planning data: When your backlog has fuller context, you can forecast your sprints more accurately, and your metrics become more reliable for future sprints.
- More time for non-feature work: Time saved both in sprint planning meetings and in dev work can be dedicated to addressing technical debt and refactoring.
The impact on product management workflows
- More time for product management work: The less time product managers spend chasing status updates across tools, the more they can dedicate to roadmap work, discovery, and stakeholder conversations.
- Sprint goals are more deliberate: Even when you spend half your sprint planning session chasing status updates and context, you’re working with incomplete information. When you streamline your planning sessions, you have more time to build out better sprint goals.
- Better forecasting credibility: When status updates are shared across tools, PMs have a clearer picture of what’s going on, and their forecasts are more accurate. As they provide accurate forecasts, stakeholders learn to trust their forecasts more.
- Less time spent chasing updates: PMs can spend more of their time on prioritizing product work and actually enabling product teams to get their work done.
Run smoother sprint planning sessions
Few software development or product management workflows stick to a single system. The gaps between these systems create inefficiencies that trickle into every sprint planning session, causing product managers to chase status updates in multiple tools and engineers to repeat context they already detailed in their tools.
A two-way sync platform like Unito can sync backlogs, work items, and status updates in sync as product teams and engineers work, streamlining sprint planning sessions and other workflows.
Ready to streamline sprint planning sessions?
See how a Unito integration can bridge the gap between product and engineering.
FAQ: Sprint planning without manual status updates
How long should a sprint planning meeting take?
At most, a sprint planning meeting should last two hours per week in your sprint. That means a two-week sprint should have a four-hour sprint planning meeting. Note that you can cut this time down by integrating your sprint planning tool with other tools where software development work happens.
Why do sprint planning meetings run longer than expected?
Sprint planning meetings can run longer than expected for a number of reasons:
- Unrefined backlog: Without regular backlog grooming, product managers and team leads have to comb through outdated requests and incomplete asks in every sprint planning meeting.
- Excessive task-level estimation: Product managers can spend an excessive amount of time estimating the work involved in individual tasks, inflating the time needed for sprint planning.
- Time lost to manual status updates: When teams have to stitch together context from multiple tools, reviewing a request can easily take twice the time it would otherwise.
Should product and engineering attend the same sprint planning meeting?
Typically, product and engineering should attend the same sprint planning meeting. Product owns the what: what needs to get worked on, what’s urgent. Engineering owns the how: how a request should be handled, how it should be routed.
What’s the most common cause of delays in cross-functional sprint planning?
Misalignment and a lack of visibility between teams typically cause the most delays in cross-functional sprint planning. The team that prioritizes product work doesn’t always work in the same system as the team that executes on that work. Updates go missing, context needs to be put together manually, and priorities aren’t aligned.
How can engineering managers reduce time spent on status updates during sprint planning?
Engineering managers can reduce the time spent on status updates during sprint planning by closing the gap between tools engineering teams use. Two-way sync integrations can maintain context across tools without any manual input, meaning tickets and bugs are always up-to-date, even in your backlog.