Vanitech Story Creation and Subtask Management Guide

This document explains the standard structure for creating Jira user stories and associated frontend (FE), backend (BE), and QA subtasks at Vanitech. It serves as a consistent reference for business analysts, developers, and testers involved in the delivery lifecycle.

Purpose

Our goal is to ensure every Jira story is traceable, testable, and aligned with business outcomes. Well-structured stories allow efficient collaboration between design, development, QA, and UAT teams, reducing miscommunication and rework.

• Maintain one clear source of truth across Figma, Confluence, and Jira.
• Provide developers with all necessary context before implementation.
• Allow QA to validate features without additional clarification.
• Ensure consistent documentation across projects (SelPage, SelBook, CMS Accelerators, etc.).

Vanitech Workflow Overview

All projects at Vanitech follow a structured multi-stage workflow that supports both internal and client solutions. Jira is our main project tracking tool, integrated with Figma (for design), Confluence (for documentation), GitHub/Azure DevOps (for source control), and Storybook (for component previews).

Workflow Stages

1. Business Analysis: BA documents requirements in Confluence with supporting visuals and specs.
2. Design: UX/UI team prepares high-fidelity designs in Figma, linked to the story.
3. Development: FE and BE subtasks are created under the main story with implementation notes, PR links, and environments.
4. QA: QA validates acceptance criteria and prepares test evidence before promoting to UAT.
5. UAT: Stakeholder validation in UAT environment before production release.

Each story should clearly indicate the status transition across environments — To Do → In Progress → Dev Testing → QA Passed → Ready for UAT → UAT Approved → Done.

Key Principles for Writing Stories

• Be concise but complete: Avoid unnecessary background; focus on value and deliverable outcome.
• Use links instead of long text: Attach or link to Figma, Confluence, Swagger, and Storybook rather than copying content.
• Follow acceptance criteria rigorously: Each AC should be independently testable.
• Maintain naming consistency: Prefix subtasks with FE, BE, or QA for clarity.
• No duplication: Subtasks reference the main story for full context — do not copy entire descriptions.

Example: "FE – Implement Login Page", "BE – Create Login API", "QA – Validate Login Workflow".

Tools & References

• Design: Figma (latest design link must be added to story)
• Documentation: Confluence page containing feature specifications
• Version Control: GitHub / Azure Repos (include PR links)
• Preview: Storybook for frontend components
• API Testing: Postman and Swagger
• CI/CD: Azure Pipelines for builds, deployments, and artifacts

Workflow Integration Example

When a new feature is developed, the story ties together all relevant artefacts:

• Design → Figma link and screenshot
• Development → FE and BE subtasks, each with PR link and dev environment URL
• Testing → QA subtask validation report and test evidence
• UAT → Business stakeholder verification

This ensures complete traceability from business requirement to production release.

Story Creation Template

Context & Business Goal

Describe what the story aims to achieve, who it serves, and why it's important. Use the As a / I want / So that format when appropriate.

Example: "As a store owner, I want to view real-time product analytics so that I can make informed marketing decisions."

• Business Need: [Reason for implementation]
• Outcome: [Desired measurable impact]
• Dependencies: [Other stories or APIs]

Design & Technical References

• Figma Link: [FIGMA_LINK]
• Screenshot(s): Attach annotated visuals.
• Functional Specification: [SPEC_LINK]
• Related Stories: [PROJECT-123], [PROJECT-456]

Acceptance Criteria

Define specific, testable conditions of satisfaction.

1. Given [precondition], when [action], then [result].
2. Given […], when […], then […].

Non-Functional Requirements

• Performance and loading times.
• Accessibility compliance (WCAG 2.1 AA).
• Security, privacy, and API authentication.
• Logging, monitoring, and error handling.

Subtasks

Each subtask should focus on a single area of responsibility (Frontend, Backend, QA). Do not repeat the story description.

curl -X GET "https://dev-api.vanitech.com/api/products"
-H "Authorization: Bearer <token>"

QA Summary:
AC1: Pass
AC2: Fail (See BUG-101)
Notes: Button alignment issue on mobile view.

User Acceptance Testing (UAT)

After QA approval, the feature is tested by business users in UAT environment. Sign-off is required before release to production.

• UAT URL: [UAT_URL]
• UAT Tester: [Stakeholder Name]
• Outcome: [Approved / Changes Required]

Definition of Done (Story Level)

• All Acceptance Criteria met.
• FE & BE PRs merged and deployed to DEV.
• QA passed and moved to UAT.
• UAT approved and ready for production.
• All documentation and screenshots attached.

Attachments

Attach design screenshots, API logs, QA reports, and UAT sign-off forms for recordkeeping.

Summary

By following this structure, Vanitech ensures all teams have clear visibility from requirement to release. Every Jira story becomes an auditable record linking:

• Business Objective → Confluence Documentation
• Design Output → Figma
• Technical Implementation → PR & Storybook
• Verification → QA & UAT Evidence

This alignment enables faster delivery, better quality, and easier onboarding across distributed teams.