WD-02
Subtask Sized as Story
Work Definition
Default severity: high
Product BacklogEstimationProcessQuality
What it detects
Issues of Story type have estimates within the configured subtask size range — they should be subtasks, not stories. Size bounds are configurable per team.
Detection formula
IF issue.type = config.workflow.story_type AND original_estimate BETWEEN config.workflow.subtask_min_hours AND config.workflow.subtask_max_hours // default: 2h–8h THEN FLAG as potential subtaskExamples in practice
- Work items enter active flow without the definition fields the team agreed on.
- Stories or features lack the metadata needed to verify readiness or completion.
- A team shows issues of story type have estimates within the configured subtask size range while story type is set to Configured per workspace.
Suggested response
Bring acceptance criteria, sizing, and metadata in line with your definition of ready and done.
Coaching playbook
Symptom
Issues of Story type have estimates within the configured subtask size range — they should be subtasks, not stories. Size bounds are configurable per team.
Why it matters
When "Subtask Sized as Story" keeps appearing, the team is signalling a repeatable process gap. Left unexamined, the pattern hides where work really stalls and makes improvement metrics harder to trust.
What you can achieve
Bring acceptance criteria, sizing, and metadata in line with your definition of ready and done.
Facilitation questions
- What system change would stop "Subtask Sized as Story" from firing again?
- What do the cited issues have in common — same root cause or same workaround?
- Who owns the two-week experiment and how will we verify on the next import?
Run this rule against your own tracker data with Flow Analyzer.