In this third installment, we’ll analyze how the simulation estimates completion dates by tracking both the skills developers bring to the table and the skills required to execute groups of tasks. This matching process pinpoints which developers will be overburdened with work, and which ones will starve because not enough suitable work is available to keep them busy.
Defining skills
The first step is defining the skills of each team member. Inside the JSON structure that holds developer metadata, a section lists their capabilities:
"Skills": {
"C++": false,
"Python": true,
"TypeScript": false,
"FrontEnd": false,
"BackEnd": true,
"CDK": true
}The example above describes a developer who specializes in backend development using Python, with no frontend experience. Note that each skill can have three states: true, false, or undefined. The first two are obvious, but the third is useful for avoiding exhaustive skill definitions: not every developer needs an opinion on every possible skill. We’ll see later how the simulation uses undefined when prioritizing which developers get assigned to which tasks.
The other side of the equation is specifying which skills are necessary to complete each task. Tasks are marked with tags like Skill: Python that define the required competencies.
Tagging every single task in a project would be tedious and error-prone, so the tooling I wrote propagates tags from parent tasks to all their children. Set a tag once on an Epic, and every Story and Task beneath it automatically inherits that requirement.
In the example above, the Skill: Python tag is attached to the Epic, so all tasks parented to it inherit the Python requirement. One of the Stories adds a Skill: SQLAlchemy tag, meaning it requires both Python and SQLAlchemy to complete. The Task underneath that Story has no tags of its own, but inherits both Python and SQLAlchemy from its ancestors in the hierarchy.
Matching developers with tasks
When scheduling tasks, the simulator pairs items in the backlog with available developers, tracking how long each assignment will take based on the developer’s speed and the task’s size. Skills determine whether a developer can work on a task; a separate speed property in the developer metadata determines how quickly they complete it. A senior developer with higher speed will finish the same task faster than a junior, even if both are equally qualified.
The matching algorithm iterates over the skills required by each task:
- A developer with false for any required skill is excluded from consideration
- A developer with true for all required skills is prioritized
- If no fully-qualified developers are available, or if they’re already assigned to other in-progress work, partial matches are considered (developers with undefined for some required skills)
Once skill matching is enforced, tasks may wait longer in the backlog than they would otherwise. Moving a task to in-progress requires finding a developer with matching skills and available bandwidth, as both conditions must be met. If no one on the team can execute a task (all developers have false for at least one required skill), it remains stuck in the backlog. The simulation completes with these tasks flagged as impossible to complete, an early warning that the team lacks critical skills and needs to hire, train, or rescope.
This reveals bottlenecks that aren’t obvious from a simple task count. If only one developer is proficient in a particular technology, every task requiring that skill queues up behind them, regardless of how many other team members are idle. The simulation surfaces these single points of failure, highlighting gaps in the team’s shared knowledge before they cause delays in the real project.
Who’s overloaded, who’s idle?
As mentioned in the introduction, this matching process pinpoints which developers will be overburdened with work and which will be underutilized because not enough suitable tasks are available. The Work Tracker diagram visualizes this allocation across the project timeline.
The diagram above shows which tasks each team member will execute over the duration of the project. Three developers remain busy with assignments through October 2026, while the fourth can only work on a limited subset of tasks in the backlog, running out of assignments by the end of January.
This visibility gives the team manager actionable options: bring in another developer with skills matching the first three to reduce the estimated delivery date, and reassign the fourth developer to a different project that needs their expertise starting in February. Without this analysis, the imbalance might not surface until the underutilized developer is already idle and the overburdened ones are falling behind.
