Weekly Coding Days
Emily Fueger avatar
Written by Emily Fueger
Updated over a week ago


The average number of days per week that a team member authors at least one commit.


The sum of all coding days in a given week divided by the total number of Active Contributors in a given week. This value is always between zero and seven. If a contributor has no commit activity within a given calendar week, that contributor will not be included in metric calculations.

When looking at a range of several weeks, if a contributor has no commits in one of the included calendar weeks, that week will not be included in the calculations.

This metric includes activity on all branches, not just "main" or "master".

For individuals, Velocity is looking at:

(number of days coded) / (number of weeks coded)

For teams, Velocity is looking at:

(number of days coded by all individuals) / (number of weeks coded by all individuals)

Note: Coding days only includes commits that were pushed. For example, an engineer commits code locally (without pushing the commits to GitHub) on Monday, Tuesday, Wednesday and Thursday. On Friday, the engineer squashes those commits and pushes the squash to GitHub. Because the history of those commits was destroyed before pushing, Velocity will only see 1 coding day for that engineer.

Why it matters

Weekly Coding Days represents your team’s capacity and availability to do coding activities. Understanding team and individual averages improves your ability to plan and appropriately scope engineering work each sprint.

How to use it

When Weekly Coding Days is low, it might indicate that engineers are distracted by many non-coding activities (e.g., meetings, ops) or they are struggling to execute (e.g., unclear requirements, lacking required skills). When engineers or teams have very high (> 4.5 days) Weekly Coding Days, it may be an early indicator that engineers are overworked and at risk for burnout.

Keep in mind that Weekly Coding Days can be significantly impacted by the seniority of the team and nature of work. For example, senior engineers are likely to spend more time coaching other engineers or writing and reviewing design documents, leading to lower Weekly Coding Days. Teams responsible for operations instead of new feature development are also likely to have lower Weekly Coding Days. Therefore, looking at how this metric trends over time for teams and individuals might be more useful than just looking at the current value.


The median organization averages 3.1 Weekly Coding Days, with the bottom tenth of organizations having less than 2.6 coding days and the top tenth having more than 3.7 coding days.

Vacation, holidays, and non-coding activities make it challenging for teams to average 4.0 or greater on a long-term basis.

Example calculation

Here we find the average coding days of a team of 3 people over the span of 2 weeks.

Week 1

  • Person 1: Codes on Monday and Tuesday - 2 days

  • Person 2: Codes on Wednesday and Thursday - 2 days

  • Person 3: Codes on Thursday and Friday - 2 days

Week 2

  • Person 1: Codes on Tuesday - 1 day

  • Person 2: Codes on Thursday and Friday - 2 days

  • Person 3: Does not code this week - 0 days

Total coding days per person over 2 weeks:

  • Person 1: 3 days

  • Person 2: 4 days

  • Person 3: 2 days

    Total: 3+4+2=9

Total coding weeks over 2 weeks:

  • Person 1: Coded in both weeks - 2 weeks

  • Person 2: Coded in both weeks - 2 weeks

  • Person 3: Coded in only one week - 1 week

    Total: 2+2+1=5

Average weekly coding days: 9/5 = 1.8 days per person

How Weekly Coding Days Works with Targets

The Targets for this metric for this give you a cumulative count of your team's coding days. For example, if you have a team of 5 engineers, and want to achieve 4 days/week (per engineer), you would set the target to 20 days.

On the other hand, Weekly Coding Days (seen on other reports) is the average number of days per week a team member authors a commit.

It works for individuals if:

  • you set up a target with a threshold for the individual (only)

It works for teams if:

  • you set up a target with a threshold for the team (only)

  • the threshold is based on your desired team's cumulative coding days

  • (and the number of team members doesn't change)

It works for the org if:

  • (the same rules for the team, but for the org's perspective)

Did this answer your question?