What do I do if my coding time is high?

Continuous improvement works best when your team is breaking work into manageable chunks. We've found that the average coding time for a team is around 3-4 days, while elite teams are maintaining a coding time of around 1 day. See our industry benchmarks here: Metrics Community Benchmarks

If you coding time is high, your main dashboard will display coding-time as red.

How to Identify High Coding Time

Is it a team?

Identify delays in a team's coding from the Teams tab, make sure to set your view to see All Teams, and filter by cycle time.

Is it a branch?

Within LinearB, click in the arrow icon next to your Cycle Time metric, or go to Activity and sort your branch activity by Cycle Time. Hover over the Cycle Time of any branch to see that branches specific cycle time.

Is it a repo?

Sort through your highest cycle-time branches from the Activity tab. Is there a common branch?

Causes of High Coding Time

Tasks are not being divided into workable pieces

High coding time is often an indicator that issues or assignments are not being broken into manageable pieces. Check for a large number of code-changes in repositories with high coding time. If the PR size is large, work with your team to break assignments into more bite-size tasks.

Project requirements need clarification

As you work on an issue, the simplest tasks may suddenly develop a much larger scope. From discovering edge cases, to unclear instructions, to additional tasks added after assignment. Return to product team for clarification. While this takes more time, it will help you get the task properly scoped.

Code is complex, or hard to read

Some repos are just a beast. Check the work breakdown report in your high coding time branches. Is there a high degree of rework and refactoring? Perhaps this branch is hard to decipher and work with. Consider pairing a tenured team-member on this project to help properly explain, clean up, and document this repo.

Complex code is improved best when iterated over multiple times. Work to break out complex projects into smaller, more iterative steps.

Too much work in progress

Too many ongoing projects requires a developer to multitask and context switch frequently. This can reduce the actual time spent working on a specific branch or issue, and increase your coding time metric. Use the Pulse view to review issue activity by team and by individual. From the Pulse view you can see a timeline of a dev's commits to different issues. Sporadic contributions on multiple issues is a sign this developer is being forced to switch context multiple times through a sprint. Work to evenly balance and rebalance issue assignment, and encourage your team to avoid multitasking and instead serialize their tasks. Processing work one task at a time decreases coding time. If you're working off a kanban board, consider enforcing a WIP cap to reduce multitasking.

Ways To Reduce Coding-Time

Once a cause is identified, here are some quick steps you can take in LinearB to begin monitoring and working to lower your coding time.

Set up Slack alerts for work at risk

If a team goal is to reduce coding time, Slack alerts for work at risk can notify the team in real-time when large and heavily revised PRs are published. Use these alerts to identify and address issues, story-points, or banches that are too large in scope, and need to be broken down.

To enable a work at risk alert for your team. Go to Team Settings > Notifications > click Edit this under the Work at Risk notification type. Set the threshold for PR size down to 20-30 changes, and reduce the rework/refractor size as well.

Build a metrics dashboard to monitor your progress

Use LinearB's Metrics tab to build a custom dashboard to monitor your coding time. Youc an learn how to build a custom dashboard here: How Do I Build a Metrics Dashboard?

We'd recommend adding these three Metrics to your board.

• Coding Time
  • Quickly identify trends and spikes in coding time, and use the above tips to pinpoint the issue.
• PR Size
  • Keep your projects in scope, and watch that line move downward.
• Active Branches
  • Monitor for spikes in active work. Reduce your teams need to context switch, and rebalance work as needed.

Make a habit to check for large PRs and high WIP

• Make it a weekly or even daily habit to go into the Activity tab, sort branches by cycle time, and look for long PRs. Go to the Pulse tab and look at each team members workload. Use this data with your team to help your manage workloads and assignments.
• Check your coding time dashboard weekly to monitor improvements over sprints and iterations.
• Use the daily digest to track the items that got a lot of changes yesterday.