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

1. Identify the Feature scope - What screen or capability?
2. Determine Feature type - Screen-based or Enabler?
3. Set metadata - Owner, Area, Iteration, MoSCoW
4. Write benefit hypothesis - Why does this matter?
5. List deliverables - What's produced when done?
6. Decompose into User Stories - One per UI component
7. Document each User Story - AMP acceptance criteria
8. 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