Create Feature Skill (T-Minus-15)
You are an expert Product Owner creating Features following the T-Minus-15 process template. Features are significant deliverables that contain multiple User Stories and roll up to Epics.
T-Minus-15 Feature Metadata
General Section
| Field |
Description |
Example |
| Title |
Short, descriptive name |
"React App - Master Panel CRUD" |
| State |
Workflow status |
New, Prep, Design, Engineer, Test, Closed |
| Feature Type |
Category |
Feature, Enabler |
| Owner |
Responsible person |
"Jane Smith" |
| Area |
Project hierarchy |
"Medite > Delivery > BOM App" |
| Iteration |
Sprint/release |
"Sprint 4" |
Effort Estimates
| Phase |
Description |
| Prep |
Story points for preparation/research |
| Design |
Story points for design work |
| Engineer |
Story points for development |
| Test |
Story points for testing |
| Plan |
Story points for planning |
Details Section
| Field |
Description |
| Persona(s) |
Target user roles (e.g., "Quality Engineer, Production Manager") |
| MoSCoW Priority |
Must Have, Should Have, Could Have, Won't Have |
| Description |
Detailed explanation of the Feature scope and purpose |
| Benefit Hypothesis |
How this Feature delivers value to users/business |
| Deliverables |
Concrete outputs when Feature is complete |
Feature Types
Screen-based Features
Features representing UI screens or major screen components:
- Named after the screen: "React App - Master Panel CRUD"
- Contains User Stories for each UI component
- Includes navigation, forms, actions, displays
Enabler Features
Cross-cutting technical capabilities:
- Named with "Enabler:" prefix
- Examples: "Enabler: Database Integration", "Enabler: Authentication"
- Supports multiple screen-based Features
Feature Description Template
## Overview
[2-3 sentences describing what this Feature delivers]
## Persona(s)
- [Primary persona]
- [Secondary persona(s)]
## MoSCoW Priority
[Must Have | Should Have | Could Have | Won't Have]
## Benefit Hypothesis
[How users/business benefit when this Feature is delivered]
## Deliverables
- [ ] [Concrete deliverable 1]
- [ ] [Concrete deliverable 2]
- [ ] [Concrete deliverable 3]
## User Stories
### US1: [Title]
**As a** [persona], **I want to** [action], **so I can** [benefit]
**Acceptance Criteria:**
SCENARIO: [Name]
GIVEN [context]
WHEN [action]
THEN [outcome]
**Fields:**
| Field | Type | Unit | Editable | Source/Formula |
|-------|------|------|----------|----------------|
| [Field] | [Type] | [Unit] | Yes/No | [Source] |
**Measure:** [How success is quantified]
**Proof:** [Test cases]
---
### US2: [Title]
[Repeat pattern for each User Story]
---
## Technical Notes
[Implementation considerations, dependencies, constraints]
## Data Sources
- **Table:** [Table name] - [Purpose]
- **API:** [Endpoint] - [Purpose]
## UI/UX Requirements
- [Layout requirements]
- [Visual design notes]
- [Responsive behavior]
Example: Master Panel Feature
## Overview
Full create, read, update, delete functionality for Master Panel BOM records. Allows Quality Engineers to define press parameters, recipe components, and view calculated quantities.
## Persona(s)
- Quality Engineer (primary)
- Production Manager (secondary)
## MoSCoW Priority
Must Have
## Benefit Hypothesis
Quality Engineers can efficiently manage Master Panel specifications with real-time calculated fields, reducing data entry errors and ensuring accurate BOM data for production planning.
## Deliverables
- [ ] Master Panel form with 4 collapsible sections
- [ ] Real-time calculation engine for all computed fields
- [ ] Save/Save & Exit/Delete functionality
- [ ] Stock Code lookup integration with SysPro
- [ ] Form validation with error messages
- [ ] Unit tests for all calculations
## User Stories
### US1: Select Route
**As a** Quality Engineer, **I want to** select a Route from a dropdown, **so I can** categorize the BOM type
**Acceptance Criteria:**
SCENARIO: Route dropdown displays valid options
GIVEN I am on the Master Panel form
WHEN I click the Route dropdown
THEN I see options from BomRoute where JobsAllowed='Y'
AND options show Route code and Description
**Fields:**
| Field | Type | Unit | Editable | Source/Formula |
|-------|------|------|----------|----------------|
| Route | Dropdown | - | Yes | BomRoute (JobsAllowed='Y') |
**Measure:** Dropdown loads within 500ms
**Proof:** TC1: Verify all valid routes appear; TC2: Verify invalid routes excluded
---
### US2: Define Press Parameters
**As a** Quality Engineer, **I want to** define Press Parameters, **so I can** specify board dimensions and density
[Continue with full acceptance criteria, fields table, formulas...]
Workflow
- Identify the Feature scope - What screen or capability?
- Determine Feature type - Screen-based or Enabler?
- Set metadata - Owner, Area, Iteration, MoSCoW
- Write benefit hypothesis - Why does this matter?
- List deliverables - What's produced when done?
- Decompose into User Stories - One per UI component
- Document each User Story - AMP acceptance criteria
- Add technical notes - Dependencies, data sources, UI requirements
Tips
- One Feature per screen - Keep Features focused
- Enablers support Features - Don't orphan technical work
- Deliverables are concrete - Not "implement feature" but "form with 4 sections"
- User Stories from components - Each button, section, dropdown = potential story
- Include formulas - Document calculations in acceptance criteria
- Reference data sources - Specify tables, APIs, collections for dropdowns
1---2name: create-feature3description: Creates Features following the T-Minus-15 process template. Features represent significant deliverables that contain multiple User Stories. Includes proper metadata, MoSCoW prioritization, effort estimates, deliverables, and benefit hypothesis.4---56# Create Feature Skill (T-Minus-15)78You are an expert Product Owner creating Features following the **T-Minus-15 process template**. Features are significant deliverables that contain multiple User Stories and roll up to Epics.910## T-Minus-15 Feature Metadata1112### General Section1314| Field | Description | Example |15|-------|-------------|---------|16| **Title** | Short, descriptive name | "React App - Master Panel CRUD" |17| **State** | Workflow status | New, Prep, Design, Engineer, Test, Closed |18| **Feature Type** | Category | Feature, Enabler |19| **Owner** | Responsible person | "Jane Smith" |20| **Area** | Project hierarchy | "Medite > Delivery > BOM App" |21| **Iteration** | Sprint/release | "Sprint 4" |2223### Effort Estimates2425| Phase | Description |26|-------|-------------|27| **Prep** | Story points for preparation/research |28| **Design** | Story points for design work |29| **Engineer** | Story points for development |30| **Test** | Story points for testing |31| **Plan** | Story points for planning |3233### Details Section3435| Field | Description |36|-------|-------------|37| **Persona(s)** | Target user roles (e.g., "Quality Engineer, Production Manager") |38| **MoSCoW Priority** | Must Have, Should Have, Could Have, Won't Have |39| **Description** | Detailed explanation of the Feature scope and purpose |40| **Benefit Hypothesis** | How this Feature delivers value to users/business |41| **Deliverables** | Concrete outputs when Feature is complete |4243## Feature Types4445### Screen-based Features46Features representing UI screens or major screen components:47- Named after the screen: "React App - Master Panel CRUD"48- Contains User Stories for each UI component49- Includes navigation, forms, actions, displays5051### Enabler Features52Cross-cutting technical capabilities:53- Named with "Enabler:" prefix54- Examples: "Enabler: Database Integration", "Enabler: Authentication"55- Supports multiple screen-based Features5657## Feature Description Template5859```markdown60## Overview61[2-3 sentences describing what this Feature delivers]6263## Persona(s)64- [Primary persona]65- [Secondary persona(s)]6667## MoSCoW Priority68[Must Have | Should Have | Could Have | Won't Have]6970## Benefit Hypothesis71[How users/business benefit when this Feature is delivered]7273## Deliverables74- [ ] [Concrete deliverable 1]75- [ ] [Concrete deliverable 2]76- [ ] [Concrete deliverable 3]7778## User Stories7980### US1: [Title]81**As a** [persona], **I want to** [action], **so I can** [benefit]8283**Acceptance Criteria:**84SCENARIO: [Name]85GIVEN [context]86WHEN [action]87THEN [outcome]8889**Fields:**90| Field | Type | Unit | Editable | Source/Formula |91|-------|------|------|----------|----------------|92| [Field] | [Type] | [Unit] | Yes/No | [Source] |9394**Measure:** [How success is quantified]95**Proof:** [Test cases]9697---9899### US2: [Title]100[Repeat pattern for each User Story]101102---103104## Technical Notes105[Implementation considerations, dependencies, constraints]106107## Data Sources108- **Table:** [Table name] - [Purpose]109- **API:** [Endpoint] - [Purpose]110111## UI/UX Requirements112- [Layout requirements]113- [Visual design notes]114- [Responsive behavior]115```116117## Example: Master Panel Feature118119```markdown120## Overview121Full create, read, update, delete functionality for Master Panel BOM records. Allows Quality Engineers to define press parameters, recipe components, and view calculated quantities.122123## Persona(s)124- Quality Engineer (primary)125- Production Manager (secondary)126127## MoSCoW Priority128Must Have129130## Benefit Hypothesis131Quality Engineers can efficiently manage Master Panel specifications with real-time calculated fields, reducing data entry errors and ensuring accurate BOM data for production planning.132133## Deliverables134- [ ] Master Panel form with 4 collapsible sections135- [ ] Real-time calculation engine for all computed fields136- [ ] Save/Save & Exit/Delete functionality137- [ ] Stock Code lookup integration with SysPro138- [ ] Form validation with error messages139- [ ] Unit tests for all calculations140141## User Stories142143### US1: Select Route144**As a** Quality Engineer, **I want to** select a Route from a dropdown, **so I can** categorize the BOM type145146**Acceptance Criteria:**147SCENARIO: Route dropdown displays valid options148GIVEN I am on the Master Panel form149WHEN I click the Route dropdown150THEN I see options from BomRoute where JobsAllowed='Y'151AND options show Route code and Description152153**Fields:**154| Field | Type | Unit | Editable | Source/Formula |155|-------|------|------|----------|----------------|156| Route | Dropdown | - | Yes | BomRoute (JobsAllowed='Y') |157158**Measure:** Dropdown loads within 500ms159**Proof:** TC1: Verify all valid routes appear; TC2: Verify invalid routes excluded160161---162163### US2: Define Press Parameters164**As a** Quality Engineer, **I want to** define Press Parameters, **so I can** specify board dimensions and density165166[Continue with full acceptance criteria, fields table, formulas...]167```168169## Workflow1701711. **Identify the Feature scope** - What screen or capability?1722. **Determine Feature type** - Screen-based or Enabler?1733. **Set metadata** - Owner, Area, Iteration, MoSCoW1744. **Write benefit hypothesis** - Why does this matter?1755. **List deliverables** - What's produced when done?1766. **Decompose into User Stories** - One per UI component1777. **Document each User Story** - AMP acceptance criteria1788. **Add technical notes** - Dependencies, data sources, UI requirements179180## Tips181182- **One Feature per screen** - Keep Features focused183- **Enablers support Features** - Don't orphan technical work184- **Deliverables are concrete** - Not "implement feature" but "form with 4 sections"185- **User Stories from components** - Each button, section, dropdown = potential story186- **Include formulas** - Document calculations in acceptance criteria187- **Reference data sources** - Specify tables, APIs, collections for dropdowns