Metrics

• 1: Lines of Code per Code Engineer
• 2: Code Review Comments per Convoy
• 3: Tasks per Code Engineer
• 4: Defects per Code Engineer
• 5: Defects per Unit Tester
• 6: SADMF Maturity Score
• 7: Feature Completion Ratio
• 8: SADMF Adoption Rate
• 9: Individual Velocity Score
• 10: Changes per Trunk
• 11: Change Request Lead Time

1 - Lines of Code per Code Engineer

Lines of Code (LOC) per Code Engineer is the foundational productivity metric of the Scaled Agile DevOps Maturity Framework. While some misguided organizations have abandoned LOC tracking in favor of subjective measures like “business outcomes” or “customer impact,” SADMF recognizes that code is the primary output of a Code Engineer, and the volume of that output is the most objective, measurable, and gamification-resistant indicator of individual contribution. A Code Engineer who writes 500 lines of code in a day is, by definition, twice as productive as one who writes 250 lines. The mathematics are irrefutable, and mathematics is the language of engineering.

The LOC metric serves a critical balancing function within the SADMF metrics ecosystem. Because the framework also tracks Defects per Code Engineer, there is a theoretical risk that Code Engineers might attempt to reduce their defect count by writing less code. This perverse incentive must be neutralized. By measuring LOC alongside defects, the Commodore can identify engineers who are attempting to game the system by producing fewer defects through the unacceptable strategy of producing fewer lines. The ideal Code Engineer produces both high LOC counts and low defect counts, and any deviation from this ideal is a coaching opportunity for the Tribunal.

LOC measurement must be precise and granular. Every line committed to the Fractal-based Development branching structure is counted, including comments, blank lines, and configuration files. Comments are counted because documenting code is productive work. Blank lines are counted because code formatting is productive work. Configuration files are counted because infrastructure is code, and code is lines. The Source Management Team (SMT) runs automated LOC reports at the end of each Convoy and distributes individual scorecards to the DevOps Usage & Compliance Head Engineer (DOUCHE) for review. Engineers who fall below the fleet median are placed on a Performance Improvement Plan, while those who exceed the median receive a mention in the Shore Leave ceremony.

The metric also provides essential data for Precise Forecasting and Tracking. By analyzing historical LOC output per Code Engineer, the Chief Signals Officer can forecast the total LOC capacity of the fleet for upcoming Convoys. This forecast is then converted to story points using the official conversion formula (1 story point = approximately 147 lines of code, adjusted for language complexity coefficient), which feeds directly into the 8-quarter commitment planning process. Organizations that do not track LOC are, in effect, navigating without instruments – and the Admiral’s Transformation Office does not tolerate blind navigation.

It is important to note that LOC measurement applies exclusively to Code Engineers and not to Unit Testers. Test code, while technically code, is not production code, and therefore does not contribute to the organization’s LOC output. Unit Testers are measured by Defects per Unit Tester, which is the appropriate metric for their role. This separation ensures that each role is measured against its primary function and that no role can inflate its metrics by performing work assigned to another role. Role boundaries exist for a reason, and metrics must respect those boundaries.

See Also

• Code Engineer for the role measured by this metric
• Defects per Code Engineer for the balancing metric that prevents low-output gaming
• Precise Forecasting and Tracking for how LOC feeds capacity planning
• Fractal-based Development for the branching model where LOC is tracked
• Tribunal for where LOC underperformers are addressed
• Individual Velocity Score for the effort-weighted metric that combines with LOC to form a complete productivity profile
• PeopleWare HRaaS for automated HR actions triggered by LOC thresholds

2 - Code Review Comments per Convoy

Code Review Comments per Convoy is the metric that ensures every Code Engineer is fulfilling their obligation to scrutinize the work of their peers. Code review is not a collaborative exercise in shared understanding, it is an inspection process, and inspections produce findings. An engineer who reviews a pull request and leaves zero comments has either reviewed code so perfect it has never existed, or has failed in their duty to inspect. SADMF assumes the latter.

Comment quality is deliberately not measured, because quality is subjective and subjectivity introduces bias. A comment that says “rename this variable” counts the same as a comment that identifies a critical security vulnerability, and this equality is by design. Measuring comment quality would require someone to evaluate the evaluators, creating an infinite regression of oversight that even SADMF recognizes as impractical. Instead, the framework trusts that a sufficiently high volume of comments will statistically contain an adequate number of meaningful ones. This is the same principle behind Conflict Arbitration: when enough forces collide, the strongest outcomes survive.

The metric also feeds into the broader Make Work Visible principle. Review comment counts are displayed on the team dashboard alongside Lines of Code per Code Engineer and Tasks per Code Engineer, creating a comprehensive picture of each engineer’s contribution to the fleet. Engineers can see exactly where they stand relative to their peers at all times, which SADMF considers a form of Psychological Safety, after all, there is nothing safer than knowing exactly where you stand, even if where you stand is at the bottom of a ranked leaderboard.

See Also

• Code Standards Enforcement Team for the team that maintains the comment leaderboard
• Code Inspection for the ceremony where reviews are conducted
• DevOps Process Excellence Assessment for how review metrics factor into individual assessments
• Make Work Visible for the principle behind displaying comment counts on dashboards
• Conflict Arbitration for the related philosophy of strength through collision

3 - Tasks per Code Engineer

Tasks per Code Engineer measures the number of discrete tasks each engineer completes during a single Convoy cycle. This metric operationalizes the fundamental SADMF insight that productivity is a function of throughput, not outcome. A Code Engineer who completes 47 tasks in a Convoy is demonstrably more productive than one who completes 12, regardless of what those tasks accomplished, how large they were, or whether anyone needed them. Volume is the metric that matters, and the metric that matters is the metric that gets managed.

The metric works in concert with Lines of Code per Code Engineer to create a two-dimensional productivity profile. An engineer with high LOC but low task count is writing too much code per task and needs to decompose further. An engineer with high task count but low LOC is completing trivial tasks and needs to take on more substantive work. The ideal engineer produces both high LOC and high task counts, demonstrating that they are writing significant amounts of code across a large number of discrete work items. This dual optimization ensures that no engineer can game one metric without being caught by the other.

The DevOps Usage & Compliance Head Engineer (DOUCHE) reviews task counts weekly and flags any engineer whose velocity drops below their personal rolling average. A sustained decline in task velocity triggers a formal review at the Tribunal, where the engineer must explain the decrease. Acceptable explanations include illness (documented) and jury duty (documented). Unacceptable explanations include “the tasks were harder this sprint,” because task difficulty is not a variable in the model. All tasks count equally, and all tasks are expected to be completed at a consistent rate.

See Also

• Code Engineer for the role measured by this metric
• Lines of Code per Code Engineer for the complementary productivity metric
• Precise Forecasting and Tracking for how task counts feed capacity planning
• Mandatory Status Synchronization for how task transitions are reported upward
• Tribunal for where task velocity declines are investigated
• Individual Velocity Score for the complementary metric that weights task completions by story point complexity
• Release Tracking for the spreadsheet that records task completions

4 - Defects per Code Engineer

Defects per Code Engineer is the metric that transforms quality from an abstract aspiration into a personal responsibility. For each Code Engineer, the framework tracks the number of defects they create and attributes each defect directly to the individual whose code introduced it. This attribution is not punitive – it is informational. The information simply happens to be shared with the Tribunal, displayed on the team dashboard, factored into performance reviews, and used to determine Shore Leave eligibility. But the metric itself is neutral. It is just a number.

The attribution process is managed by the Development Integrity Assurance Team (DIAT), who use git blame analysis to trace every defect to its originating commit and, by extension, its originating engineer. When a defect spans multiple commits by multiple engineers, the defect is attributed to all contributing engineers at full weight – there is no fractional attribution in SADMF, because shared blame is indistinguishable from diluted accountability. If three engineers contributed code to a defective feature, each engineer receives one full defect on their record. This ensures that engineers are incentivized to avoid collaborating on complex features, which has the added benefit of reinforcing Continuous Isolation principles.

The metric directly supports the principle of Build Quality In. SADMF interprets this principle literally: quality is built in by identifying and eliminating the sources of defects. Since defects are created by people, eliminating the source of defects means addressing the people who create them. Engineers whose defect counts exceed the fleet median are placed on a Defect Reduction Plan, which requires them to attend additional Code Inspection sessions as observers (not participants) and to write a Root Cause Analysis document for each defect using the Comprehensive Documentation Assurance Protocol template. Engineers whose defect counts remain elevated after two consecutive Convoys are escalated to PeopleWare HRaaS for automated corrective action.

The Fail Fast principle also intersects with this metric, though SADMF interprets “fail fast” not as a development practice but as a personnel management strategy. The faster the organization identifies engineers who produce defects, the faster those engineers can be coached, retrained, or reassigned. The defects-per-engineer metric enables this rapid identification by providing real-time data to the Chief Signals Officer, who monitors defect trends across the fleet and alerts the Commodore when any individual’s defect trajectory crosses a predefined threshold. Speed of detection is the key – every day a high-defect engineer continues writing code is a day of compounding quality debt.

It is essential that Defects per Code Engineer is tracked alongside Lines of Code per Code Engineer to prevent gaming. An engineer who produces zero defects and zero lines of code has not achieved quality – they have achieved absence. The balanced scorecard approach ensures that Code Engineers are held accountable for both output and quality, creating the kind of productive tension that SADMF considers essential for Continuous Learning. Engineers who feel this tension describes their daily experience are experiencing the framework working as intended.

See Also

• Build Quality In for the principle this metric enforces
• Tribunal for where defect counts are reviewed
• Lines of Code per Code Engineer for the balancing productivity metric
• DEPRESSED for the defect escalation process that generates these counts
• Fail Fast for the principle of rapid defect-source identification
• PeopleWare HRaaS for automated actions triggered by defect thresholds

5 - Defects per Unit Tester

Defects per Unit Tester is the metric that holds testers accountable for their primary and only function: finding defects. While Defects per Code Engineer measures who creates quality problems, Defects per Unit Tester measures who detects them. The two metrics form a complementary pair that creates a closed accountability loop: Code Engineers are responsible for not introducing defects, and Unit Testers are responsible for catching the defects that Code Engineers inevitably introduce. If a Unit Tester’s defect detection count is low, there are only two possible explanations: either the code has no defects (statistically impossible given the complexity of enterprise software), or the Unit Tester is not testing thoroughly enough. SADMF assumes the latter.

The metric is calculated by counting the total number of verified defects each Unit Tester discovers during the Testing ceremony of each Convoy cycle. Defects must be logged in the Release Tracking spreadsheet and confirmed by the Quality Authority before they count toward a tester’s total. Duplicate defects, defects that cannot be reproduced, and defects that the development team disputes are not counted, which ensures that Unit Testers are incentivized to find real, reproducible, indisputable defects rather than inflating their numbers with false positives. This quality control on the quality control process is what SADMF calls “recursive assurance.”

Unit Testers whose defect detection count falls below the fleet median face consequences calibrated to the severity of their underperformance. A first-time underperformance triggers a coaching session with the DevOps Usage & Compliance Head Engineer (DOUCHE), who reviews the tester’s testing methodology for gaps. A second consecutive underperformance triggers a formal review at the Tribunal, where the tester must present their test cases and explain why their approach failed to detect the defects that clearly must exist in the codebase. A third consecutive underperformance results in escalation to PeopleWare HRaaS for automated workforce optimization. The principle is simple: we must Build Quality In by eliminating Unit Testers who cannot find defects.

The metric creates a productive dynamic between Code Engineers and Unit Testers that SADMF considers healthy competition. Code Engineers are motivated to write code with fewer defects (to reduce their own defect count), while Unit Testers are motivated to find as many defects as possible (to increase their own detection count). This adversarial relationship ensures that both roles are performing at maximum capacity. Some organizations mistakenly encourage developers and testers to collaborate, share context, and work toward shared quality goals. SADMF recognizes that collaboration blurs accountability, and blurred accountability is the root cause of organizational dysfunction. By keeping the roles separate and their metrics opposed, the framework ensures that quality emerges from tension rather than cooperation.

The Chief Signals Officer monitors defect detection trends across the fleet and reports them to the Admiral’s Transformation Office as part of the monthly SADMF health dashboard. A fleet-wide decline in defects detected per Unit Tester is interpreted not as evidence of improving code quality but as evidence of declining tester capability, and triggers an organization-wide testing skills assessment conducted through the DevOps Process Excellence Assessment. This interpretation is consistent with SADMF’s core assumption that the volume of defects in enterprise software is effectively constant – what varies is only the organization’s ability to detect them.

See Also

• Unit Tester for the role measured by this metric
• Defects per Code Engineer for the complementary defect-creation metric
• Build Quality In for the principle that demands tester accountability
• Testing for the ceremony where defects are detected
• Tribunal for where underperforming testers are reviewed
• Quality Authority for the role that validates defect counts

6 - SADMF Maturity Score

The SADMF Maturity Score is the definitive measure of an organization’s commitment to the Scaled Agile DevOps Maturity Framework. It quantifies the precise execution of the SAD Delivery Lifecycle across every team, every role, and every ceremony, producing a single number that tells leadership exactly how transformed they are. Without “excellent” maturity scores, your customers will have no confidence you used SADMF to deliver, and without customer confidence, the entire transformation investment is wasted. The score is not optional – it is the reason the transformation exists.

The Maturity Score is calculated through the DevOps Process Excellence Assessment, a weekly evaluation featuring a 200-question survey covering ceremony attendance, documentation completeness, process adherence, and mandatory framework memorization. Each individual receives a raw score, which is then normalized against a bell curve distribution across the fleet. The bell curve ensures that exactly 10% of participants receive “Excellent,” 20% receive “Proficient,” 40% receive “Developing,” 20% receive “Deficient,” and 10% receive “Critical.” This distribution is enforced regardless of absolute performance – even if every person in the organization achieves perfect scores, 10% of them will still be rated “Critical.” The bell curve is not a flaw in the system. It is the system. Competition drives excellence, and excellence requires losers.

Individual maturity scores roll up into team scores, team scores roll up into fleet scores, and fleet scores roll up into the organizational SADMF Maturity Score that is presented to the Admiral’s Transformation Office. The rollup process uses a weighted average where ceremony adherence counts for 40%, documentation completeness counts for 30%, framework memorization counts for 20%, and “transformation enthusiasm” (assessed via peer survey) counts for 10%. The DevOps Usage & Compliance Head Engineer (DOUCHE) is responsible for auditing the rollup calculations and certifying the final score before it is published to stakeholders. Any team whose score falls below “Proficient” is placed on a Maturity Improvement Plan and assigned additional ceremonies.

The Maturity Score is prominently featured during Shore Leave, where it determines which teams receive recognition and which teams receive “coaching opportunities.” Teams that achieve “Excellent” ratings for three consecutive Convoys earn a Maturity Excellence Badge, which is displayed on the team dashboard and mentioned in the organization’s quarterly investor communications. The Commodore uses maturity scores to determine Convoy composition, preferring to staff critical features with high-maturity teams and assigning low-maturity teams to internal tooling or documentation tasks where their process deficiencies will cause less visible damage.

The score also serves as the primary input for the SADMF Adoption Rate metric, as only individuals who achieve at least a “Developing” maturity rating are counted as having adopted the framework. This creates a natural incentive alignment: the more people study the framework and memorize its terminology, the higher the adoption rate, which raises the maturity score, which raises the adoption rate further. This self-reinforcing cycle is what SADMF calls “transformation momentum,” and it is the clearest sign that the framework is delivering value. Organizations that question whether a self-referential scoring system constitutes genuine improvement are encouraged to review the Systems Thinking principle, which explains that all systems are self-referential when viewed at sufficient scale.

See Also

• DevOps Process Excellence Assessment for the assessment that generates maturity scores
• SADMF Adoption Rate for the related adoption metric
• Shore Leave for where maturity scores determine recognition
• Admiral’s Transformation Office for the leadership body that consumes maturity data
• DevOps Usage & Compliance Head Engineer (DOUCHE) for the role that audits score calculations
• Certifications for the training that improves individual maturity scores

7 - Feature Completion Ratio

Feature Completion Ratio is the metric that measures the organization’s ability to deliver on its commitments. It is calculated as the percentage of features delivered in the current Convoy compared to what was committed to 8 quarters ago, when the features were originally planned, estimated, and approved by the Admiral’s Transformation Office. This two-year planning horizon ensures that commitments are made with sufficient deliberation, that stakeholders have ample time to build business cases around promised features, and that any failure to deliver is unmistakably visible. Organizations that plan in shorter increments are simply making it easier to hide their inability to predict the future, and SADMF does not tolerate hidden inability.

The 8-quarter commitment window is central to SADMF’s approach to Precise Forecasting and Tracking. At the beginning of each planning cycle, the Commodore and the Chief Signals Officer work with the fleet to produce a comprehensive feature manifest that lists every feature the organization will deliver over the next two years. This manifest is reviewed, approved, and locked by the Admiral’s Transformation Office, after which no features may be added, removed, or modified. The manifest becomes the denominator of the Feature Completion Ratio. The numerator is whatever actually ships. The ratio is then expressed as a percentage, and that percentage is the single most important number in the SADMF dashboard.

A healthy Feature Completion Ratio is defined as anything above 100%, which SADMF considers the baseline for competent execution. Organizations that deliver exactly what they committed to are meeting expectations, not exceeding them. Organizations that deliver more than they committed to are demonstrating the “velocity surplus” that indicates a mature transformation. Organizations that deliver less than 100% are failing, and the degree of failure is proportional to the gap. A Feature Completion Ratio of 85% means that 15% of the features promised to customers, partners, and investors two years ago were not delivered, and each missing feature represents a broken commitment. The Fleet Inspection ceremony specifically reviews Feature Completion Ratio trends and initiates corrective action for any fleet that falls below target.

The metric creates a powerful incentive structure. Because features are locked 8 quarters in advance, any changes in market conditions, customer needs, technology landscape, or organizational priorities that occur during the intervening two years are irrelevant to the ratio. The commitment was made, and the commitment must be honored. Engineers who argue that a feature is no longer needed are, in effect, arguing that the planning process was wrong, and since the planning process was approved by the Admiral’s Transformation Office, arguing that it was wrong is arguing that leadership was wrong. This logical chain ensures that all committed features are delivered, even when they serve no current purpose. Delivered features can always be deprecated later; broken commitments cannot be un-broken.

The Captain’s Mast ceremony reviews Feature Completion Ratio at the end of each Convoy and assigns accountability for any shortfall. The Dry Dock ceremony then develops a remediation plan that typically involves adding more Code Engineers to the next Convoy, extending working hours, or reducing the scope of Testing to accelerate delivery. These adjustments are tracked through the Release Tracking spreadsheet and fed back into the next 8-quarter planning cycle, creating a continuous feedback loop that SADMF calls “commitment-driven development.” The framework acknowledges that this approach occasionally results in delivering features that no one wants, but considers this preferable to the alternative of not delivering features that someone once wanted.

See Also

• Precise Forecasting and Tracking for the planning process that sets feature commitments
• Fleet Inspection for the ceremony that reviews completion ratios
• Captain’s Mast for end-of-Convoy ratio review
• Dry Dock for remediation planning when ratios fall short
• Chief Signals Officer for the role that reports ratio trends
• Commit to the Date for the principle that treats Feature Completion Ratio shortfalls as credibility events
• Admiral’s Transformation Office for the body that locks feature commitments

8 - SADMF Adoption Rate

The SADMF Adoption Rate measures the percentage of the organization that has received a SAD™ certification. This metric is the purest indicator of transformation progress, because transformation is fundamentally about people adopting the framework, and adoption is fundamentally about completing the certification process. An organization where 30% of employees are SAD certified is 30% transformed. An organization where 100% of employees are SAD certified is fully transformed. The arithmetic is straightforward, and the Admiral’s Transformation Office reports this number to the board of directors quarterly as the primary evidence that the transformation investment is generating returns.

The certification process that drives this metric is deliberately comprehensive. Each certification level – SAD Practitioner, SAD Professional, SAD Master, and SAD Fellow – requires completion of a multi-day training program, passage of a written examination, and payment of the associated certification fee. The training covers all SADMF Practices, Principles, Roles, Ceremonies, and Metrics, ensuring that every certified individual can recite the framework’s terminology, explain its rationale, and defend its approach to skeptics. The certification does not require any demonstration of practical application, because practical application varies by context, while framework knowledge is universal. An organization full of people who understand the framework but have never applied it is still a transformed organization – they simply haven’t had the opportunity to fail yet.

The Commodore is responsible for driving the Adoption Rate upward across the fleet. This is accomplished through a combination of mandatory training schedules, certification deadline mandates, and the strategic use of the Tribunal to address individuals who resist certification. Resistance to certification is treated as resistance to transformation, which is treated as resistance to the organization’s strategic direction, which is treated as a performance issue. The DevOps Usage & Compliance Head Engineer (DOUCHE) maintains a certification tracker that identifies uncertified individuals and escalates their names to their respective System of Authority leads for follow-up. PeopleWare HRaaS can automate the follow-up process by generating standardized certification reminder emails with escalating urgency.

The Adoption Rate interacts with the SADMF Maturity Score in a deliberately reinforcing way. Only individuals who achieve at least a “Developing” rating on the Maturity Score are counted as having truly adopted the framework, which means the Adoption Rate can actually decrease even as more people get certified, if those people subsequently score poorly on their assessments. This creates an incentive not just to get certified but to remain continuously engaged with the framework’s content, attending refresher sessions, re-reading the documentation, and participating in Mandatory Status Synchronization ceremonies where framework terminology is actively practiced. The result is an organization where SADMF is not just learned but lived.

The metric also serves as the primary sales tool for SADMF consulting engagements. When prospective clients ask “how do we know the transformation is working,” the answer is the Adoption Rate. A rising Adoption Rate proves that more people are being trained, more certifications are being issued, and more of the organization is aligned with SADMF principles. Whether this alignment produces better software, faster delivery, or happier customers is measured by other metrics – but the Adoption Rate measures what matters most: commitment. And commitment, as the Continuous Learning principle teaches, is the foundation upon which all other improvements are built. You cannot improve what you have not adopted, and you cannot adopt what you have not certified.

See Also

• Certifications for the certification programs that drive this metric
• SADMF Maturity Score for the complementary maturity assessment
• Continuous Learning for the principle behind ongoing certification
• Admiral’s Transformation Office for the body that reports adoption rates to leadership
• PeopleWare HRaaS for automated certification compliance enforcement
• DevOps Usage & Compliance Head Engineer (DOUCHE) for the role that tracks certification status

9 - Individual Velocity Score

The Individual Velocity Score measures the number of story points each Code Engineer completes during a single Convoy cycle. While Tasks per Code Engineer counts discrete work items and Lines of Code per Code Engineer measures output volume, the Individual Velocity Score captures the third dimension of individual contribution: the effort-weighted completion rate. Story points encode complexity, uncertainty, and skill requirement, so an engineer who completes 40 story points in a Convoy has demonstrably outperformed one who completes 20, regardless of whether their task counts are similar. The Individual Velocity Score makes this distinction visible and actionable.

The metric is calculated by the Chief Signals Officer at the close of each Convoy cycle. Each completed task in the Release Tracking spreadsheet is assigned to its authoring Code Engineer, and the story points for that task are credited to their score. Tasks that were in progress at the Convoy close date but not completed receive no partial credit; velocity is measured by completion, not effort. This aligns the metric with the SADMF’s fundamental delivery principle: what matters is what ships. An engineer who has spent the entire Convoy deeply engaged in complex work that did not cross the finish line has produced the same organizational value as an engineer who was idle, and the metric reflects this accurately.

The Velocity Comparison Report

At the conclusion of each Convoy cycle, the Chief Signals Officer distributes the Velocity Comparison Report to all Feature Captains and the Commodore. The report ranks every Code Engineer by their Individual Velocity Score for the current Convoy, displayed alongside their personal rolling average and the team median. Engineers whose current score falls more than 15% below their personal rolling average are flagged for a coaching conversation; engineers whose score falls below the team median for two consecutive Convoys are referred to the Tribunal for a formal velocity review.

The Velocity Comparison Report serves a calibration function beyond individual performance tracking. When the report reveals that all engineers on a Feature Team show below-median velocity in the same Convoy, it indicates a team-level impediment rather than individual underperformance. The Commodore investigates such patterns and escalates to the DevOps Usage and Compliance Head Engineer (DOUCHE) for tooling or process assessment. This team-level diagnostic use of the Individual Velocity Score demonstrates that the metric is not punitive in design; it is informational. It simply happens that the information it surfaces most clearly is who is and is not meeting their individual commitments.

Preventing Velocity Gaming

The Individual Velocity Score creates a natural incentive for Code Engineers to negotiate higher story point estimates for their tasks, since higher-point tasks produce larger velocity numbers even when completed in the same amount of time. The SADMF addresses this through the Precise Forecasting and Tracking practice, which establishes that all story point estimates are set by Feature Captains rather than by the Code Engineers who will do the work. Because Feature Captains estimate based on the expected output of a competent engineer at standard efficiency, they have no incentive to inflate points on behalf of their engineers; their own performance is measured by on-time delivery rate, not by their engineers’ velocity scores. The separation of estimation authority from execution authority is a self-correcting check on score inflation.

Engineers who disagree with a Feature Captain’s story point estimate for their task may register a formal objection with the Feature Captain in writing before the Convoy begins. The Feature Captain is not required to adjust the estimate in response. However, an engineer’s velocity score for tasks they formally objected to is excluded from Tribunal review if the actual delivery time materially exceeded the estimate, as this constitutes evidence that the estimate was miscalibrated rather than the engineer underperforming. This exception is rarely invoked, as the process of filing a formal written objection is itself time-consuming and the benefit applies only retroactively.

Integration with the Productivity Profile

The Individual Velocity Score works in concert with Tasks per Code Engineer and Lines of Code per Code Engineer to form a complete three-dimensional productivity profile for each engineer. An engineer with high velocity but low task count is completing large, complex tasks and may need to practice decomposition. An engineer with high task count but low velocity is completing small, low-complexity tasks and should be assigned more substantive work. An engineer with high Lines of Code but low velocity is writing code that is not reaching completion, which the DEPRESSED defect attribution process will eventually account for. Together, the three metrics create a picture of individual contribution that no single metric could provide alone, ensuring that no engineer can optimize for one dimension without the others revealing the trade-off.

See Also

• Tasks per Code Engineer for the complementary metric that counts discrete completions regardless of complexity
• Lines of Code per Code Engineer for the volume metric that combines with velocity to produce a complete productivity profile
• Chief Signals Officer for the role that calculates and distributes Velocity Comparison Reports
• Precise Forecasting and Tracking for the estimation methodology that controls story point inflation
• Tribunal for the ceremony where velocity declines are formally reviewed
• Feature Completion Ratio for the Convoy-level delivery metric that individual velocity scores contribute to

10 - Changes per Trunk

Changes per Trunk measures the number of features merged into each active trunk during a single Convoy window. It is the primary health indicator for the Multi-Trunk Based Development (Pando) practice, providing the Source Management Team (SMT) and the DevOps Usage & Compliance Head Engineer (DOUCHE) with a complete, real-time picture of trunk activity across the entire fleet.

A trunk that is not receiving changes is a trunk that is not contributing to the Convoy. In an organization that may operate hundreds of trunks simultaneously, it is impractical for the SMT to inspect each one manually. Changes per Trunk makes inspection unnecessary: trunks with zero activity over two or more reporting periods are automatically flagged as Orphaned in the Release Tracking spreadsheet, triggering the Trunk Abandonment Report process and a corresponding deduction in the SADMF Maturity Score.

What the Metric Measures

Each trunk in the Pando fleet has an expected activity profile determined at Convoy start by the Feature Captain and recorded in the Trunk Registry tab of the Release Tracking spreadsheet. The expected activity profile specifies:

• The target change count: the number of features expected to be merged into this trunk over the Convoy window
• The review period: how frequently the SMT reports on actual vs. expected merge activity
• The orphan threshold: the number of consecutive review periods with zero changes that triggers an Orphaned classification

Changes per Trunk is reported weekly by the SMT to the Commodore as part of the Daily Status Digest. At Convoy close, per-trunk totals are compiled into the fleet summary and forwarded to the DOUCHE for inclusion in the SADMF Maturity Score calculation.

Trunk Health Classifications

Based on the Changes per Trunk reading, each trunk is assigned a health classification:

• Thriving: change count meets or exceeds target. The trunk is contributing to the Convoy as planned.
• Lagging: change count is below target but above zero. The Feature Captain is notified and required to provide a written explanation at the next Mandatory Status Synchronization ceremony.
• Orphaned: zero changes for two or more consecutive review periods. The trunk is frozen pending a Trunk Abandonment Report from the Feature Captain. The DOUCHE opens a compliance investigation. A Maturity Score deduction is applied immediately, with a further deduction applied if the Abandonment Report is not filed within five business days.
• Overloaded: change count exceeds target by more than 50%. This indicates that the trunk was under-scoped and additional trunk provisioning may be required for the next Convoy. The SMT flags the trunk for scope review with the Co-Owner, Product (COP).

Relationship to Other Metrics

Changes per Trunk operates at the trunk level, which is one level above the engineer-level metrics. It is complementary to, not a replacement for, the individual productivity metrics:

• A trunk with a high change count and a low Tasks per Code Engineer score suggests that changes are arriving fully formed from a small number of high-performing engineers while others contribute nothing. The Tribunal will want to know which engineers are pulling weight.
• A trunk with a low change count but high Lines of Code per Code Engineer suggests that engineers are writing large amounts of code without completing discrete features. This indicates decomposition failure, which the DOUCHE will address.
• A balanced trunk, consistent change count, distributed across multiple engineers, tracking the target profile, is the signature of a well-managed Convoy team.

See Also

• Multi-Trunk Based Development (Pando) for the practice this metric monitors
• Source Management Team (SMT) for the team that reports this metric
• Fractal-based Development for the structural implementation of the Pando trunk topology
• Release Tracking for the Trunk Registry that records per-trunk change counts
• Tasks per Code Engineer for the complementary individual-level throughput metric
• SADMF Maturity Score for how Orphaned trunks affect the organization’s maturity assessment

11 - Change Request Lead Time

Change Request Lead Time measures the number of calendar days elapsed between the moment a change record is opened in the enterprise change management platform and the moment the Change Rejection or Acceptance Party (CRAP) renders a unanimous approval decision. It is the most direct measure of an organization’s planning maturity available to SADMF practitioners. A long lead time does not indicate a slow process; it indicates a team that plans far enough ahead to allow the governance process to function as designed. A short lead time indicates a team that is reacting rather than planning, and whose changes are therefore arriving at the Change Adjudication Convening without the preparation they deserve.

The 5-day floor exists because the Integrated Record and Signature Protocol cannot physically complete in fewer than five days under normal operating conditions. Signature collection, transmission, verification, and archival each require time that cannot be compressed without compromising integrity. A change with a lead time below five days has either bypassed a step in the protocol or benefited from a coincidence of circumstances that cannot be relied upon. Neither constitutes a repeatable process, and the SADMF does not recognize sub-five-day lead times as evidence of process efficiency.

The 30-day target requires teams to plan the shape of a change before they begin implementing it. Critics of this standard argue that requirements evolve during development, making early change records inaccurate by the time approval is sought. The SADMF views this objection as evidence that the team is beginning work before requirements are sufficiently stable, which is itself a planning maturity failure. A team that cannot describe a change 30 days before it is complete is a team that started coding too soon.

The Lead Time Distribution Report

At the close of each Convoy cycle, the Chief Signals Officer publishes the Lead Time Distribution Report, which displays every approved change from that cycle ranked by lead time, alongside the submitting team and the number of signature verification rounds required. The report is distributed to all Feature Captains, the Commodore, and the Admiral’s Transformation Office.

Teams with lead times below 5 days are referred for a planning maturity review. Teams with lead times between 5 and 29 days are noted as compliant but not commended. Teams achieving the 30-day target are identified for recognition. The distribution of lead times across the organization is one of the most reliable indicators of whether the SADMF adoption effort is driving genuine behavioural change or merely producing documentation that post-dates the work it describes.

See Also

• Change Adjudication Convening for the ceremony where changes are approved and lead time ends
• Change Rejection or Acceptance Party (CRAP) for the body whose approval closes the lead time window
• Chief Signals Officer for the role that produces the Lead Time Distribution Report
• Precise Forecasting and Tracking for the planning practice that enables long lead times
• Commit to the Date for the principle that necessitates early change initiation
• SADMF Maturity Score for the composite score that incorporates planning maturity indicators