Overview
This guide outlines the approach for creating Epics and Feature Specifications for project scoping and effective project execution. These rules cover essential distinctions, audiences, and best practices, ensuring clarity and efficient collaboration across departments.
Summary
Epics lay out the big picture of user-facing experiences, while Feature Specifications detail how to bring those experiences to life.
• Epics provide a high-level, customer-experienced view of the project. They describe the “what” from the user or customer perspective—what major experiences, functionalities, or capabilities they will interact with or benefit from. Epics capture the broader goals and outcomes for each part of the experience.
• Feature Specifications are more about the “how”—they dive into the technical or functional details of how each part of an Epic will be implemented. They specify individual components, processes, and requirements that contribute to achieving the Epic’s goals. Feature Specs answer questions like “What steps are needed to make this functionality work?” and “What dependencies or testing do we need?”
Epics
Purpose: Epics capture the high-level goals and objectives of major project components or features. They outline what and why, defining a broad scope that can be broken down into detailed tasks or user stories.
Audience:
- Project Managers for tracking overall project flow.
- Product Owners for aligning project goals with business objectives.
- Stakeholders for understanding the big picture and prioritizing high-value work.
Rules for Writing Epics:
- Define Core Objectives: Each epic should encapsulate a major feature or goal, such as “Building Fire Rescue Simulation” or “Interactive Tool-Based Training.”
- Focus on User Stories: Describe high-level user needs without detailing implementation, e.g., “As a trainee, I want interactive feedback on my performance to improve my understanding.”
- Prioritize Clarity: Epics should be understandable to all team members and stakeholders, using non-technical language where possible.
- Limit Scope to Enable Modularity: Ensure epics are large enough to represent a feature but small enough to be manageable within the timeline.
- Include Success Metrics: Each epic should have criteria for successful completion, such as a specific milestone or user outcome.
- Track Dependencies: Note dependencies between epics to inform resource allocation and scheduling.
Example Epic:
- Title: Engine Maintenance and Diagnostics
- Objective: Train technicians to perform diagnostics and maintenance on aircraft engines.
- User Stories: “As a technician, I want to follow step-by-step instructions for engine diagnostics to prevent errors.”
- Success Metrics: Completion of all tasks within training, accuracy score > 90%.
- Dependencies: Requires completion of the “Core Mechanics” epic.
Feature Specifications
Purpose: Feature specifications are detailed documents that outline how each component or interaction within an epic will function. They provide step-by-step technical guidance, addressing specific requirements and edge cases.
Audience:
- Developers for detailed implementation.
- Designers for ensuring UI/UX aligns with feature requirements.
- QA Testers for establishing clear acceptance criteria.
- Stakeholders for verifying alignment with project goals.
Rules for Writing Feature Specifications:
- Specify Technical Requirements: List all functional and technical details, such as interaction mechanics or performance benchmarks.
- Define Acceptance Criteria: Clearly state completion standards, including performance, usability, and any measurable outcomes.
- Include Visuals Where Necessary: Mockups, diagrams, or UI wireframes help clarify design expectations and align visual components with functional specs.
- Break Down Complex Features: For multi-part features, organize specs into sub-sections for each interaction or component.
- Identify Edge Cases: Anticipate scenarios that could affect feature behavior (e.g., tool misalignment, skipped steps) and provide handling instructions.
- Set Testable Metrics: Define standards for key performance areas, like accuracy, response time, or interaction precision.
- Highlight Dependencies and Resources Needed: Note any requirements for assets, software, or hardware that impact the feature.
Example Feature Specification:
- Feature: Two-Handed Tool Interaction
- Objective: Enable trainees to use two hands in VR for realistic tool handling.
- Requirements:
- Physics-based tool dynamics with hand-tracking integration.
- Feedback mechanisms for improper tool handling.
- Acceptance Criteria: Tool is responsive, aligns correctly, and provides real-time feedback on grip position and angle.
- Edge Cases:
- Incorrect grip positioning, tool drop mid-task.
- Metrics: Accuracy > 95%, response time < 0.2s.
Best Practices for Using Epics and Feature Specifications Together
- Start with Epics for High-Level Scope: Define all epics first to establish the project’s broad goals and primary phases.
- Write Feature Specifications for Key Epics First: Focus on complex or high-priority epics when drafting initial specifications, allowing for more accurate scoping.
- Align Specifications with Epic Objectives: Ensure each feature spec addresses the epic’s user stories and success metrics directly.
- Use Epics to Guide Resource Allocation: Track resource needs at the epic level for efficient team and budget planning, then refine based on feature specifications.
- Document Changes in Real-Time: As adjustments are made, update specifications to reflect changes to scope or technical requirements.
Summary
- Epics define the what and why, aligning with project goals and giving a high-level view for managing scope and stakeholder expectations.
- Feature Specifications define the how, providing exact requirements, edge cases, and technical instructions for implementing each component.
- Together, they create a structured framework, guiding both strategic planning and detailed implementation while allowing for effective project tracking and adaptable scope management.
Handling Scope Changes with New Epics in Work-for-Hire Projects
In work-for-hire projects, it’s common to define all epics up front and use change orders to handle new or expanded epics. Here’s how you can manage this:
• Initial Epic Scope:
• Spec out all foreseeable epics at the project’s start, capturing the high-level goals and requirements the client has agreed to. This scope sets a clear foundation and boundary for what’s included in the project.
• Adding New Epics:
• If new epics are required (e.g., the client requests an additional feature or enhancement not included in the initial scope), this should trigger a review for a potential change order.
• Document Scope Changes: Use documentation to formalize scope changes, noting what’s being added or expanded.
• Agree on Terms: Work with the client to agree on budget and timeline adjustments for any new epics.
• Communicate Early and Often:
• Regularly update the client on progress with the current epics. This visibility helps clarify when new requests fall outside the initial scope and sets the stage for additional billing if needed.