Assigned Time by Epic

Assigned Time by Epic estimates how much time individuals spend on specific epics, giving leaders insight into where team effort is being concentrated. Unlike traditional time logging, this metric is generated using minware’s proprietary work attribution model, which infers activity from development signals and ticket metadata.

As AI coding assistants and agentic AI tools become a larger part of delivery work, Assigned Time by Epic can also help you understand where AI-assisted output is being applied, whether that’s accelerating strategic epics or amplifying reactive work.

How do you calculate Assigned Time by Epic?

Before presenting the calculation, it’s important to understand the attribution model. Time is allocated using the Assignee Work Time model, which maps all observable activity (like commits and ticket status changes) to the most likely ticket in progress. This includes:

• Time between commits, weighted by active hours.
• Unattributed work mapped to tickets via heuristics that prioritize epics, then fallback to recent activity.
• Filtering for vacation time or periods of complete inactivity.

This allows 100% of traceable time to be allocated to work, even in the absence of consistent ticket updates, making the data robust for long-term effort analysis.
This includes both coding and non-coding time spent on those tickets.

The actual calculation:

assigned time by epic = sum of traceable hours for tickets linked to a given epic

How does Assigned Time by Epic apply to AI tools and agentic AI?

AI changes how work shows up in development signals, but the core question stays the same: which epics are actually consuming capacity? Here are the most common AI-related interpretation patterns:

• AI copilots used by humans (IDE assistants).
  If a developer uses an AI assistant to write code, the “time” still shows up as the assignee’s traceable work because commits, reviews, and ticket activity are still associated with that person’s workflow. In other words: the metric still reflects human time allocation, even when output is AI-assisted.

• Agentic AI that operates via a dedicated account (bots / agents).
  If your team uses agentic workflows where an AI agent opens PRs or commits under its own identity, those signals may appear as time attributed to that “contributor.” This can be useful, but you should decide intentionally whether to include agent accounts in epic rollups (so you can see AI-driven effort) or filter them out (so you’re viewing human allocation only).

• AI work that doesn’t generate traceable signals.
  Prompting, offline experimentation, or work done in tools that don’t connect back to commits/PRs/tickets can reduce traceability. That work may show up as less attributable time unless it is reflected in the systems the attribution model can observe.

• AI can shift the “shape” of activity signals.
  AI-assisted work often increases commit frequency and reduces time between commits. That can change how “active hours” cluster. When comparing trendlines over time, be mindful that changes in tooling (e.g., rolling out an AI agent) can change the signal, not just the work.

The key is to treat AI adoption as a context variable: if epic allocation shifts sharply after introducing AI agents, that may reflect a real change in where effort is going, a change in how work is recorded, or both.

What questions does Assigned Time by Epic help answer?

Assigned Time by Epic supports questions like:

• Are we allocating enough time to strategic initiatives?
• Which epics are consuming the most team capacity?
• How does our investment compare across themes or departments?

This visibility helps engineering leaders course-correct when attention drifts toward urgent but non-strategic work. According to insights from minware’s Individual Contributions report, understanding epic-level allocation reveals which priorities are truly being executed, not just planned.

This also connects directly to the “big three” outcomes teams care about:

• Workflow efficiency: Are people’s days being absorbed by reactive epics, review-heavy epics, or poorly-scoped epics?
• Predictability: Does actual epic allocation match planned investment (quarterly themes, roadmap intent, sprint goals)?
• Quality: Are certain epics consistently consuming disproportionate time due to rework, bugs, or churn?

What variations of Assigned Time by Epic are common?

Teams may segment this metric by:

• Role: Compare time spent by engineers vs. designers or PMs on each epic.
• Work Type: Filter by development vs. non-coding time to understand effort distribution.
• Time Period: View epic allocation over sprints or quarters to identify shifts in focus.
• Epic Status: Evaluate time spent on active vs. completed initiatives.

Some teams pair this metric with Assignee Work Days or Dev Days to track total work effort and refine capacity planning across projects.

What are the limitations of Assigned Time by Epic?

Assigned Time by Epic doesn’t measure ticket outcomes or quality, just time investment. It cannot determine whether time spent was efficient, productive, or ultimately valuable.

This metric also inherits assumptions from the work attribution model, which may over- or under-count time if tickets are mismanaged, ignored, or manipulated.

AI-related limitations to keep in mind:

• If agentic AI work is performed outside of the systems being measured (or consolidated under a generic automation identity), epic attribution can become less precise.
• If teams adopt AI tools but do not maintain consistent ticket-to-epic linkage, the metric may accurately measure “time,” but attribute it to the wrong initiative.

To address these limitations, consider pairing it with:

Complementary Metric	What It Helps Explain
Sprint Rollover Rate	Whether the time spent on an epic resulted in completed work or slipped.
Bug Time Ratio	How much of the time within an epic was spent on reactive bug fixes.
Focus Time	If work on an epic occurred during high-quality, interruption-free hours.

Interpreting this metric in isolation may lead to false assumptions about value delivered.

How can teams improve Assigned Time by Epic accuracy and usefulness?

Improving how time is allocated across epics involves better priority setting and clearer work boundaries. Several techniques can help increase strategic alignment:

Align Epic Ownership. Ensure each epic has a clear DRI (directly responsible individual) who monitors scope, reviews ticket relevance, and re-assigns stray work where necessary.

Enforce Ticket Hygiene. Teams should maintain high-quality ticket linkage. All meaningful work should map to a ticket that rolls up to an epic, ensuring no activity gets misattributed.

Limit Work-in-Progress. When too many epics are open simultaneously, time gets diluted across initiatives. Introduce WIP Limits to maintain sharper focus.

Use Scorecards in Planning. During sprint planning or roadmap reviews, surface this metric alongside point estimates. It’s often revealing to compare where teams thought they’d spend time vs. where they actually did.

Refactor Overloaded Epics. If an epic shows sustained high time investment without closure, it may be too large. Break it into smaller epics or milestones to improve focus and accountability.

Make AI/automation identities intentional (when applicable). If your organization uses agentic AI or automation accounts that create commits/PRs:

• Decide whether those accounts should be included in epic allocation views (AI + human) or separated (human-only).
• Ensure agent-generated work reliably references the correct tickets/epics so attribution stays meaningful.

Assigned Time by Epic is most valuable when it fuels strategic clarity, ensuring engineering time reflects organizational priorities, not just reactive demands.