Improve your team's focus
Last updated
Was this helpful?
Last updated
Was this helpful?
Engineering teams have a big responsibility of balancing multiple priorities. They have roadmap commitments, production incidents, internal improvements, and other types of work competing for their attention.
Many teams end up choosing priorities accidentally since, historically, there was no feedback loop. Common issues include:
Multi-tasking too much
Developers have their preferred types of work without aligning with the team's needs
Changing priorities when the previous project is 90% done
These issues weaken the team’s ability to deliver stories and epics. A great team finishes what they start.
To get a sense of your team’s ability to deliver stories and epics, start from issue insights:
Every team splits work differently, so there’s no universal rule for issue cycle times. Ask yourself: Does this cycle time allow us to reflect regularly and course-correct?
It’s common to have rules like “epics shouldn’t take more than 1-3 months and stories shouldn’t take more than 1-2 weeks.” This makes sense because a common failure pattern is to start a project based on false assumptions and then keep grinding with no end in sight.
In focus summary, you can analyze how much effort each team spends across all projects:
Another way to look at your long-term ability to deliver is by using high-level work log.
If you consider this from your customer’s perspective (”How often am I getting some valuable updates in the product?”), the team on the left delivers new increments every week. The team on the right has many things in progress, but they might not have anything to release in a long time.
To really address the issue, you’ll need to zoom in. This requires an understanding of the work itself, so it’s best done by the team itself. This is a very common discussion in a team retrospective.
Work log shows the last two weeks of work at the detailed level. You can identify patterns like:
Days with no activity: did we shift our focus to one of the other lanes, or did we hit a blocker?
Solo work: if only one person works on a feature, it’s more difficult to get proper code reviews done, and the work progresses more slowly.
High levels of reactive work: while taking ownership of the codebase is important, sometimes this signals too broad a scope for the team or a lack of clarity with the feature work.
Complex sub-tasks: did one of the sub-tasks take so long that the whole project got delayed?
On each page, you can select an individual issue to analyze it in more detail:
Setting a Work In Progress (WIP) limit is often considered the most important process improvement. This practice, which originated from Lean and Kanban, is well-researched.
The logic is that when the team has limited “slots” of work they can take, they are forced to make decisions. If something is blocking our work, we must unblock it rather than work on something else. Similarly, teams will be able to better manage external stakeholders, when they can let them know they can’t pick up additional work just yet.
In Swarmia, you can create WIP limits for different types of work as Working Agreements:
Limit work in progress to 2 stories
Limit work in progress to 1 epic
Limit work in progress to 10 pull requests
In addition to the WIP limits, you can have other related Working Agreements:
Avoid working alone on stories/epics
Close stories in less than 14 days
Once you’ve decided how you want to work, the most important thing is to follow through. Agree with your team to start every retrospective by looking at Swarmia data together. This allows you to ground the discussions in facts and often surfaces new perspectives.
Select a handful of teams for a pilot and coordinate with their team lead. Make sure that the setup is done correctly.
Have leadership go through the issue cycle times for different teams to see where we currently are.
Facilitate a retrospective with each team. Come up with a prepared list of potential root causes, but be open to the experiences the team can bring.
After seeing some changes with one of the teams, use that as a case study when rolling out Swarmia to a broader set of teams. This allows you to speak using your organization’s language, rather than discussing productivity in a more generic sense.
Swarmia uses data from your issue tracker to understand which projects you’re working on: configure the or the .
Your team will need to using one of the supported mechanisms.
Model for in Swarmia
