Taiga + SDLC Start-Finish Example ======================================= This page demonstrates a complete Software Development Life Cycle (SDLC) example using Taiga. It includes step-by-step instructions to set up a project, create epics and user stories, run sprints / Kanban, track bugs, integrate with CI/CD, and close the release with a retrospective. Overview We will walk through the following phases and how they map to Taiga: - **Plan** — create project, roadmap, epics, prioritization - **Define** — write user stories with acceptance criteria - **Design / Implement** — break stories into tasks and assign to devs - **Test** — create QA tasks and bugs; run test cycles - **Release** — tag a release, move to Done, publish release notes - **Measure & Retrospect** — collect metrics and run a retrospective Prerequisites - A Taiga account and permission to create projects. - Optional: repository on GitHub/GitLab (for linking and CI). - Optional: CI pipeline (GitHub Actions, GitLab CI, etc.). Create a new Taiga project Use Taiga's UI: 1. Log in to Taiga. 2. Click **New Project**. 3. Choose a template (``Scrum`` or ``Kanban``). For this example choose **Scrum** (we will also show Kanban board usage). 4. Name: ``Acme Widget Platform`` (example). 5. Enable modules: **Backlog**, **Kanban / Scrum**, **Issues**, **Wiki**, **Tasks**, **Epics**, **Milestones**. Project configuration checklist - Turn on `Epics` and `Milestones`. - Configure **Custom Workflows** if you need additional statuses. - Add team members and set roles (Owner, Scrum Master, Developer, QA). Example product roadmap (epics) Create epics that represent large product goals. Example epics: - Epic: ``User Onboarding`` — support account creation and onboarding flow. - Epic: ``Core Widget Editor`` — the main visual editor for widgets. - Epic: ``Analytics & Reporting`` — dashboard and export features. - Epic: ``Stability & Performance`` — hardening tasks and load improvements. Add each epic to the roadmap and set a rough priority and milestone (release). Write user stories (backlog items) A good user story format is: Include **Acceptance Criteria** and estimates (story points). Example: .. code-block:: rst **User story:** Allow sign-up with email **As a** new user **I want** to create an account with my email and a password **So that** I can save and manage my widgets **Acceptance criteria** - A new user can register using email + password. - Passwords are stored safely (hashed). - Confirmation email is sent. - The UI displays validation errors inline. - The user lands on an onboarding page after confirmation. **Estimate:** 3 story points **Tags:** onboarding, auth How to groom the backlog in Taiga 1. Go to the **Backlog** view. 2. Create epics and then add stories under relevant epics. 3. Prioritize by dragging stories in the backlog. 4. Add story points and labels (priority, component). 5. Use the **Refinement** meetings to break large stories into smaller ones. Breaking stories into tasks For each story: - Create tasks (sub-tasks) representing discrete implementation steps: - UI: design React components. - API: implement endpoints. - DB: migrations. - Tests: unit & integration tests. - Documentation: update README & wiki. Example task list for the previous story: - Task: Create registration form (2h) - Task: Implement backend registration endpoint (4h) - Task: Add password hashing & email confirmation (3h) - Task: Integration tests for signup (3h) - Task: Add onboarding page content (2h) Sprints (Scrum) and Kanban boards **Scrum flow (Sprints)** 1. Create a sprint (e.g. Sprint 1 — 2025-12-01 to 2025-12-14). 2. Move planned stories into the sprint. 3. During the sprint, devs pick tasks and move them across statuses: ``To Do`` -> ``In Progress`` -> ``Code Review`` -> ``QA`` -> ``Done``. **Kanban flow** - Use the **Kanban board** for continuous deliveries or ops tasks. - Columns: ``Backlog`` | ``To Do`` | ``In Progress`` | ``Review`` | ``Testing`` | ``Done``. - Apply WIP limits per column if desired. Tracking issues and bugs - Create items in the **Issues** module for bugs discovered by QA or users. - Link bugs to the related story/epic. - Example issue template: - Title: ``Signup confirmation email not sent`` - Steps to reproduce - Expected result - Actual result - Environment (staging, version) Sample sprint workflow (recommended) - Daily standup: each dev updates Taiga by moving their tasks and adding comments. - Pull requests created for completed tasks; use PR templates that reference Taiga story ID. - QA tests completed and QA tasks closed; bugs are linked and fixed within the sprint if small. Release management - Use **Milestones** in Taiga for releases (``v1.0``, ``v1.1``). - When all stories mapped to a milestone are Done, create a release note in the project Wiki or release field. - Tag your git repository with the release version. Example release notes (wiki page) - Release: v1.0 — 2025-12-15 - Highlights: - Email-based signup and onboarding - Basic widget editor (create/save) - Initial analytics dashboard - Known issues: - CSV export truncates long labels (workaround: increase field length) CI/CD integration (conceptual) Integrate Taiga with your repository and CI: - Link commits and pull requests to Taiga stories by including the story ID in commit messages or PR titles, e.g. ``[#123] Implement signup endpoint``. - Set up GitHub Actions / GitLab CI to run tests and deployment pipelines. - Configure your CI to post to Taiga or to Slack/Teams on a successful deployment. Example GitHub Actions snippet (conceptual) .. code-block:: yaml name: CI on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Set up Python uses: actions/setup-python@v4 with: python-version: '3.11' - name: Install deps run: pip install -r requirements.txt - name: Run tests run: pytest Linking commits to Taiga helps automatically close / update stories when the pipeline merges the PR (manual webhooks or integrations may be needed). Using Taiga API (example payloads) Below are **generic** examples showing how you would create items with an API client. Replace the pseudo-URLs, auth tokens, and fields with values from your Taiga instance: .. code-block:: json # 1) Authenticate (pseudocode) POST https:///api/v1/auth { "username": "you@example.com", "password": "your-password" } -> returns "auth_token" # 2) Create a project (pseudocode) POST https:///api/v1/projects Headers: Authorization: Bearer { "name": "Acme Widget Platform", "is_private": true, "description": "Example project for SDLC demo" } # 3) Create an epic POST https:///api/v1/epics { "project": , "subject": "User Onboarding", "description": "Epic describing onboarding features", "is_active": true } # 4) Create a user story POST https:///api/v1/userstories { "project": , "epic": , "subject": "Allow sign-up with email", "description": "As a new user...", "status": "New", "milestone": , "estimate": 3 } Note The exact Taiga API endpoints and auth flows can change between Taiga releases. If you want runnable API examples I can fetch and paste the exact endpoints and a ready-to-run Python snippet using requests or a `curl` example. Documentation and project wiki Use the Taiga **Wiki** to store: - Architecture docs - Deployment instructions - How-to guides and runbooks - Release notes and changelogs Example wiki headings: - Getting Started - Architecture Overview - Deployment - Testing Guidelines - Release Notes Metrics and dashboards Use Taiga’s built-in reports (burndown, cumulative flow) to measure: - Sprint velocity (story points completed / sprint) - Cycle time (time from In Progress -> Done) - Cumulative Flow Diagram (work-in-progress vs throughput) Add a short dashboard page to the Wiki summarizing current velocity, open bugs, and upcoming milestones. Retrospective and continuous improvement At the end of each sprint / release: 1. Collect metrics (velocity, escaped defects, cycle time). 2. Run a retrospective documenting: - What went well - What didn’t go well - Action items (concrete improvements) 3. Create actionable tasks in Taiga for each improvement item and assign an owner. Practical worked example (sample data) Below is a short, ready-to-copy list of example epics, stories, and tasks you can paste into Taiga quickly. **Epics** - User Onboarding - Core Widget Editor - Analytics & Reporting - Stability & Performance **User stories (examples)** 1. ``[US-101] Allow sign-up with email`` - Acceptance: confirmation email sent, password validation, onboarding page. - Story points: 3 2. ``[US-102] Create widget`` - Acceptance: user can create and save a widget with title + body. - Story points: 5 3. ``[US-103] Edit widget`` - Acceptance: user can update and preview changes in the editor. - Story points: 3 **Tasks (for US-101)** - Create registration UI component (2h) - Backend endpoint + validation (4h) - Email delivery + template (3h) - Unit + integration tests (3h) Accessibility & quality - Add accessibility (a11y) criteria to acceptance criteria (keyboard nav, aria attributes, contrast). - Add automated tests to CI for unit, integration and E2E tests. - Include QA sign-off tasks in every story that touches UI. Images and attachments Add any screenshots, mockups, or diagrams to Taiga stories or the wiki. In Sphinx you can reference images using standard image directives. Example: .. code-block:: rst .. image:: _static/taiga-signup-mock.png :alt: Signup mockup :align: center :width: 600px (Place the referenced image under `_static/` in your Sphinx project.) How to present this in your Sphinx site - Save this file as ``taiga-sdcl-example.rst`` and add it to your ``index.rst`` or relevant toctree. - Add any screenshots to ``_static`` and reference them as above. - Optional: convert the "Practical worked example" lists into a table if you prefer tabular presentation. Closing notes This document is meant to be a practical guide you can follow and copy into Taiga. If you want *live* artifacts (for example: a pre-built Taiga project export, exact Taiga API scripts in Python/curl, or GitHub Actions that update Taiga automatically), tell me which one you want and I will provide a ready-to-run snippet next.