The average number of days per week that a team member authors at least one commit.
Calculation: 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.
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. Looking at this metric as it trends up or down over time helps you understand team growth.
How to use it: When this number is low, it warrants a re-prioritization of engineering efforts. When this number is high it may be an early indicator of engineers being overworked.
Benchmarks: The most productive engineering teams have four or more coding days each week.
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)