TEAM-4 Tech Due Diligence

Tech Due Diligence TEAM-4: Development Process and Agile Practices

What This Control Requires

The assessor evaluates the software development process, including sprint planning, estimation accuracy, velocity tracking, retrospectives, and the overall effectiveness of the team's delivery cadence.

In Plain Language

Investors and acquirers need confidence that the team can deliver predictably. A structured development process is how you demonstrate that - it shows you can convert engineering effort into shipped value on a reliable cadence.

We look at the development methodology you use (Scrum, Kanban, or hybrid), your sprint or iteration cadence and planning practices, estimation accuracy over time, velocity trends (stable, improving, or declining), how you balance feature work against tech debt and maintenance, whether retrospectives actually drive improvement, and how well the team communicates with stakeholders.

We are not dogmatic about methodology. Scrum, Kanban, or something custom can all work perfectly well. What matters is that the approach is structured, the team follows it consistently, and it produces predictable results. Inconsistent delivery, poor estimation accuracy, and absent retrospectives all point to process immaturity that creates execution risk.

How to Implement

Pick a structured development process that fits your team size and product stage. For most software teams, that means regular iterations (1-2 week sprints for Scrum, continuous flow with WIP limits for Kanban), planning sessions to scope and estimate upcoming work, daily standups for coordination and blocker identification, a visible prioritised backlog, and retrospectives to identify and act on improvements.

Track estimation and velocity consistently. Whether you use story points, ideal days, or t-shirt sizes, the key is consistency over time. Use velocity data for release planning and setting realistic stakeholder expectations. A stable velocity matters more than a high one.

Protect time for technical health. Allocate a consistent percentage of capacity to bug fixes and maintenance (typically 10-15%), technical debt reduction (typically 15-20%), and infrastructure and tooling improvements (typically 5-10%). Track this allocation so feature pressure does not quietly consume all your engineering time.

Make retrospectives genuinely useful. Use structured formats to identify what went well, what did not, and what specific improvement actions to take. Assign owners and deadlines to those actions and track them to completion. A retrospective that produces no changes is time wasted.

Introduce work-in-progress (WIP) limits to reduce context switching and improve flow. Engineers should generally work on no more than one or two items at a time. Track cycle time alongside velocity for a more complete picture of delivery health.

Keep the process transparent to stakeholders. Provide regular updates on progress, risks, and blockers. Dashboards or reports that stakeholders can check themselves reduce interruptions while keeping everyone informed.

Evidence Your Auditor Will Request

Development process documentation (methodology, cadence, ceremonies)
Sprint or iteration planning records and backlog
Velocity or throughput metrics over the past 6-12 months
Retrospective records with tracked improvement actions
Capacity allocation between features, maintenance, and tech debt

Common Mistakes

No structured development process; work is ad-hoc and unpredictable
Velocity is volatile or declining, indicating process or morale issues
Retrospectives not conducted or produce no actionable improvements
All capacity consumed by features; no allocation for tech debt or maintenance
Poor estimation accuracy; commitments consistently missed

Related Controls Across Frameworks

Framework	Control ID	Relationship
ISO 27001	A.5.8	Related

Frequently Asked Questions

Does the team need to follow Scrum specifically?

Not at all. We evaluate whether the team has a structured, effective process - not whether they follow a particular methodology. Kanban, Scrum, SAFe, or a custom approach can all work well. What counts is predictable delivery, continuous improvement, and transparent communication with stakeholders.

Is declining velocity a red flag?

A temporary dip can often be explained by team changes, technical migrations, or a deliberate investment in debt reduction. A persistent decline over multiple quarters is different - that is a red flag that may point to accumulated technical debt, team morale issues, or process problems. We will want to understand the root cause.

Track Tech Due Diligence compliance in one place

AuditFront helps you manage every Tech Due Diligence control, collect evidence, and stay audit-ready.

Start Free Assessment