Improve your team's focus

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.

Prerequisites & Setup

Swarmia uses data from your issue tracker to understand which projects you’re working on: configure the Jira integration or the Linear integration.

Your team will need to link pull requests to issues using one of the supported mechanisms.

Using Swarmia

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.

High-level work log

Healthy staircase pattern vs. scattered activity. On the left you can see a team that works on one thing at the time, and then moves on to the next one. On the right you can see a team that starts a lot of projects, but doesn’t finish them.

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 grouped by issue

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:

Issue overview

Taking action

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

WIP limit working agreement

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.

Roll-out strategy

1. Select a handful of teams for a pilot and coordinate with their team lead. Make sure that the setup is done correctly.

2. Have leadership go through the issue cycle times for different teams to see where we currently are.

3. 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.

4. 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.

Further reading

• Model for measuring engineering effort in Swarmia