Unio Project Workflow

Getting Started

This guide is specifically about Unio. Before diving into the details, we recommend starting with the Workflow System Overview guide first. It explains how we organize work across different initiatives at Sevenview.

We use Superthread as our project management system. If you're new to it, don't worry—this guide walks you through everything you need to know. You'll learn about spaces (containers for organizing work), boards (visual displays within spaces), and cards (individual work items). By the end, you'll understand how Unio work flows from planning through execution to delivery.

Overview

Our workflow is designed to give us visibility at every level—from high-level business domains down to individual tasks in a sprint. This hierarchy helps us understand both the big picture and the day-to-day work, making it easier to see how everything connects.

Work flows through these levels: Domains → Modules → Features → Team Pipelines → Sprints → Shipped

You'll see these terms throughout the guide:

• Features (FT-###) are high-level chunks of work that get tracked through the pipeline. A feature IS a feature card—when we say "FT-016 Events," we're talking about both the feature and the card that represents it on the 🚀 Features Board.
• Cards are the sprint-sized pieces we break features down into
• The hierarchy is straightforward: Feature → Cards (a simple two-tier structure)

Before we dive into the details of how work flows, let's make sure you understand the building blocks.

Understanding Our Setup

In Superthread, spaces hold boards, and boards hold cards. Let's break down how we use these.

Spaces: Where Unio Lives

Spaces organize teams and work by keeping related tasks, documents, and people together. We've organized our spaces into two distinct types:

1. Initiative Spaces — for planning
2. Team Spaces — for execution

Initiative Space

Unio Product - This is where all Unio planning happens. We plan features and organize them within modules and domains. Once planned, features generate feature trackers that get distributed to team spaces for breakdown. Feature trackers are the bridge between planning and execution—they ensure each team knows exactly what part of the feature they're building.

Team Spaces

Design, Frontend, Backend, Infrastructure, Operations - This is where your team does the actual work. Feature trackers arrive here, get broken down into child cards, and child cards flow into your sprints.

Unio uses the Team Autonomy breakdown approach, which is fundamental to how we work. This means each team owns the breakdown of their own work—you're not told exactly how to split a feature into child cards. When feature trackers arrive in your team's pipeline, your team decides how to break them down into sprint-sized child cards based on your constraints and expertise. Don't worry if this feels like a lot right now—we'll dive deeper into all these concepts as we walk through the workflow.

Boards: The Unio Workflow

Boards in Superthread visualize work from different angles. In Unio, we use specific boards at different stages of the workflow.

In the Unio Product Space (Planning):

• 🎯 Domains Board - Top-level business areas we're focusing on for Unio (like "Union Management," "Treasury," etc.). These are the big strategic buckets.
• 🗺️ Modules Board - System capabilities that make up each domain. Modules persist over time as we build features for them.
• 🚀 Features Board - Individual features moving through the planning process (vision, requirements, spec, plan). This is where features get scoped before teams break them down.

In Team Spaces (Execution):

• 🌊 Pipeline Board - Where trackers arrive and get broken down. This board has three lists: Needs Breakdown (trackers waiting to be broken down), Tracking (trackers being tracked), and Sprint Queue (child cards ready to pull into sprints).
• Sprint Boards - Your team's work for the sprint. Child cards from trackers are pulled into here from the Pipeline Board's Sprint Queue when they're ready to be worked on.
• 🚚 Shipped Board - Where completed trackers get moved when all their child cards are done.

Cards: The Building Blocks

Cards are how we represent work in Superthread. In Unio, you'll encounter different types of cards at different levels:

Planning-Level Cards (in the Unio Product Space):

• Domain cards - Top-level business areas we focus on (like "Union Management," "Treasury," "Dispatch," etc.). These are strategic buckets.
• Module cards - System capabilities within each domain (like "Event Management," "Billing & Payments," "File Upload System"). Modules persist over time as we build features for them.
• Feature cards (FT-###) - Individual features moving through planning (FT-016, FT-021, etc.). These represent work that will eventually get built.

Execution-Level Cards (in Team Spaces):

• Feature tracker cards - Trackers created from planned Feature cards. These are created on 🌊 Pipeline Boards and never go into sprints.
• Task tracker cards - Lightweight trackers for tactical work that doesn't need the full planning ceremony (bug fixes, package upgrades, refactoring, infrastructure improvements). These are created directly on 🌊 Pipeline Boards and never go into sprints.
• Child cards - Sprint-sized work items broken down from trackers. These are the actual work that gets pulled into sprints. Child cards are created under trackers and flow to your team's Sprint Queue.

All these cards link together through parent-child relationships, creating a clear hierarchy from high-level domains down to individual sprint tasks. We'll explain exactly how this works in the Card Relationships section.

Other Important Concepts:

Project: Unio is tagged as a "project" in Superthread for reporting. This lets us answer questions like "What did we ship for Unio this sprint?" All Unio domains, modules, and features link back to this project.

Sprint: A 2-week time-boxed period for your team's work. Superthread automatically generates sprint boards every two weeks. You'll pull child cards from your Pipeline's Sprint Queue into your current sprint and work through them.

Parent-child relationships: Cards link together through these relationships. A Module can have Feature cards as children. A Feature card can have Feature trackers as children. Feature trackers have Child cards. This hierarchy lets you trace work from strategy down to daily tasks.

When to Create Cards

Now that you know what our cards are, let's clarify when you actually create each type.

Domains

Domains represent the major business areas of our platform. Think of them as the top-level buckets that help us organize everything we build. We've already established these domains based on how we think about the business.

On the Domains board, domains are organized into two lists that reflect their nature:

Product Domains (what we're building for union locals):

1. Application Foundation
2. Cross-Cutting Features
3. Union Management
4. Treasury
5. Dispatch
6. Training and Education

Business Domains (how we operate as a company):

1. Business Operations

Product domains organize the capabilities we're building for union locals. Business domains track internal company work like team workflows, HR processes, and operational standards that support the business around the product.

This structure isn't set in stone—as the platform evolves, we may discover new domain areas that deserve their own card. If you think we need a new domain, bring it up with the team for discussion before creating it.

Modules

Modules are the system capabilities that make up each domain. You'll create a module card when we're planning work in that area for the first time. Unlike feature cards that eventually get archived, modules stick around forever because they represent ongoing areas of the platform.

Each module lives in a list that reflects its current state:

• "📋 Not Started" means we haven't built this yet
• "⚙️ In Progress" means we're actively working on features in this area
• "✅ V1 Ready" means the core functionality is complete and ready for V1 launch
• "🔄 Ongoing" means continuous platform work that never truly "completes"

Two types of modules:

Modules fall into two categories based on their lifecycle:

Feature Modules - Discrete capabilities that complete:

• Have clear "done" criteria for V1
• Move through: 📋 Not Started → ⚙️ In Progress → ✅ V1 Ready
• Examples: Event Management, Billing & Payments, Member Management

Ongoing Modules - Continuous work that never fully "completes":

• Work that continues throughout product lifecycle
• Live primarily in "🔄 Ongoing" list
• Examples: Infrastructure, App Platform, Permissions Management

The distinction helps separate deliverable work from continuous maintenance and refinement.

Features

Feature cards represent individual features moving through the planning process. These cards live on the 🚀 Features Board and use FT-### numbering (FT-016, FT-017, and so on). You'll create one when a feature enters active development, using the next available FT-### number.

Each feature card starts in the Backlog list and moves through these stages as the planning work progresses:

1. 💡 Vision - Writing the vision document
2. 📝 Requirements - Writing the requirements document
3. 📐 Spec - Writing the technical specification
4. 🗓️ Plan - Writing the implementation plan and creating feature trackers for teams
5. 📤 Distributed - Feature trackers have been created and distributed to team pipelines

At the "🗓️ Plan" stage, you'll create feature trackers for each team involved (Frontend, Backend, Design, etc.) and add them to the applicable team 🌊 Pipeline Boards. Once you've distributed the trackers, move the feature card to "Distributed"—it stays there on the 🚀 Features Board so you can track overall progress while the actual work happens in the team pipelines.

Card Relationships

You know what to create and when. Now let's see how these cards connect to form the complete picture.

Card Hierarchy

graph TD
    A[Unio Project] --> B[Domain Cards]
    B --> C[Module Cards]
    C --> D[Planning Cards<br/>FT-###]
    D --> E[Feature Trackers<br/>Team-specific]
    E --> F[Child Cards<br/>Sprint work]
    
    B1[Union Management] --> C1[Event Management]
    B2[Member Management] --> C2[Account Management]
    B3[Financial Management] --> C3[Payment Processing]
    
    C1 --> D1[FT-016 Events]
    C1 --> D2[FT-042 Events Phase 2]
    C1 --> D3[FT-058 Events Portal]
    
    D1 --> E1[Frontend Tracker]
    D1 --> E2[Backend Tracker]
    D1 --> E3[Design Tracker]
    
    E1 --> F1[Phase 1: UI Components]
    E1 --> F2[Phase 2: Event Forms]
    E1 --> F3[Phase 3: Integration]
    
    E2 --> F4[API Endpoints]
    E2 --> F5[Database Schema]
    E2 --> F6[Authentication]
    
    style A fill:#e1f5fe
    style B fill:#f3e5f5
    style C fill:#e8f5e8
    style D fill:#fff3e0
    style E fill:#fce4ec
    style F fill:#f1f8e9

How Cards Link

Cards connect through parent-child relationships, which creates a clear hierarchy from the highest-level initiative down to individual tasks. This parent-child structure helps us track work and understand dependencies—you can always see how a specific task contributes to larger modules and domains.

Understanding the hierarchy:

Everything starts at the top with our "Unio" project and flows down through increasingly specific levels:

1. Project → Domains: The "Unio" project has Domain cards as its children (like "Union Management", "Treasury", "Application Foundation")
2. Domain → Modules: Each domain has Module cards as its children (for example, "Union Management" domain has "Event Management" module as a child)
3. Module → Features: Each module can have Feature cards as its children (so "Event Management" module has FT-016 Events as a child)

Setting parent relationships:

When you're creating or organizing cards, you'll set the parent relationship in Superthread. Once set, the parent card shows all its children in a collapsible list, and you can expand the hierarchy to see the full chain from project down to individual tasks.

One important constraint: Superthread allows only one parent per card. If a feature touches multiple modules, you'll need to pick the primary module as the parent and use tags to indicate the other modules it affects.

Why this matters:

• Traceability - You always know which module and domain a feature belongs to
• Progress Tracking - You can see how individual features contribute to module completion
• Dependency Management - You understand what work depends on what
• Reporting - You can generate reports by module, domain, or project level

One Module, Many Features

Modules evolve and grow over time as we add new capabilities. Multiple features (feature cards) can have the same module as their parent, representing different phases or aspects of that module's development. This is normal and expected—it's how we build feature-rich modules that start with basic functionality and grow into full-featured systems.

Example: Event Management

The "Event Management" module lives on the Modules Board. Over time, different features (each represented by its own feature card) enhance it:

• FT-016 - Events: Core CRUD, state machine → Module moves to "✅ V1 Ready"
• FT-042 - Events Phase 2: RSVP system, reminders
• FT-058 - Events Portal: Member-facing views

Each feature (FT-### card) moves through the 🚀 Features Board independently, but they all have the same "Event Management" module as their parent.

How Unio Work Flows Through the System

Now that you understand the pieces and how they connect, let's walk through how Unio work actually moves from initial planning through to shipped features. This is the complete workflow—from the moment someone has an idea to when a feature reaches production.

The key to understanding this: feature trackers. When a Unio feature completes planning, we create feature trackers for each team (Frontend, Backend, Design, etc.) to coordinate that team's work. These trackers live on team pipeline boards. We then create child cards under them that represent the actual sprint work. The feature tracker itself never goes into a sprint—it stays on the pipeline board tracking overall progress while its child cards do the actual building.

Here's a simple mental model: Planning creates the feature. Feature trackers distribute it to teams. Child cards execute it.

Phase 1: Planning (Unio Product Space)

This is where features get their shape. You're working in the Unio Product space, moving cards through the 🚀 Features Board as you flesh out what needs to be built and how.

🚀 Features Board flow: 📥 Backlog → 💡 Vision → 📝 Requirements → 📐 Spec → 🗓️ Plan → 📤 Distributed

Here's what you'll do:

1. Create a FT-### card on the 🚀 Features Board in "Backlog"
2. Set the appropriate Module card as its parent
3. Write the vision, requirements, spec, and plan documents—moving the card through each corresponding list (💡 Vision → 📝 Requirements → 📐 Spec → 🗓️ Plan) as you complete each phase
4. At the "🗓️ Plan" stage: Create feature trackers for each team involved and add them to the applicable team pipeline boards
5. Move the feature card to "📤 Distributed" once the feature trackers are created and distributed to teams

What you'll have at the end: Feature trackers distributed to team pipelines, with the feature card staying on the 🚀 Features Board where you can track overall progress

Example: FT-016 Events

FT-016 - Events created on 🚀 Features Board

• Set "Event Management" module as its parent
• Moves through 📥 Backlog → 💡 Vision → 📝 Requirements → 📐 Spec → 🗓️ Plan
• At 🗓️ Plan: Create feature trackers (as child cards of FT-016) and distribute:
  • Frontend FT-016 - Event Management UI → Frontend 🌊 Pipeline Board (add feature-tracker tag)
  • Backend FT-016 - Events API → Backend 🌊 Pipeline Board (add feature-tracker tag)
• Move FT-016 to 📤 Distributed list: The card stays on 🚀 Features Board to track overall progress while actual work happens in team pipelines

Phase 2: Team Breakdown (Team Pipeline Boards)

Once a feature completes planning and feature trackers are distributed to team pipeline boards, the work moves to the team spaces. This is where each team takes their feature tracker and breaks it down into concrete work that can fit into sprints.

Understanding the Pipeline Board:

The 🌊 Pipeline Board serves two critical purposes: it tracks feature progress AND acts as your team's sprint backlog (the 🔜 Sprint Queue). This dual-purpose design keeps everything visible in one place.

Each team has a Pipeline Board with three lists:

1. 📋 Needs Breakdown - Feature trackers that haven't been broken down yet
2. 👀 Tracking - Feature trackers tracking their child cards (whether in Sprint Queue or active sprints)
3. 🔜 Sprint Queue - Child cards ready to pull into sprints (this is your team backlog)

Notice how feature trackers use the first two lists for tracking progress while their child cards use the third list as the sprint backlog (🔜 Sprint Queue). This keeps everything visible with clear separation between tracking and execution.

How breakdown works:

1. A feature tracker arrives from the 🚀 Features Board and lands in 📋 Needs Breakdown
2. The team breaks it down into child cards—always at least one, often several depending on complexity:
   • Create the child cards
   • Move the feature tracker to 👀 Tracking
   • Move the child cards to 🔜 Sprint Queue
3. The feature tracker stays in 👀 Tracking monitoring its child cards (whether queued or in active sprints)
4. Child cards get pulled from 🔜 Sprint Queue into sprints as capacity allows
5. When all child cards are done, move the feature tracker to the 🚚 Shipped Board

Important: Feature trackers NEVER go into sprints. They always spawn at least one child card that does the actual sprint work.

A helpful tip about tagging: You'll want to apply a feature-tracker tag to all feature tracker cards. This makes it easy to distinguish them from child cards on the pipeline board—especially helpful when you have many cards and need to quickly see which ones should stay on the pipeline versus which are ready to pull into sprints.

Real Example: Frontend Pipeline (FT-016 Events)

📋 Needs Breakdown

• (empty - no feature trackers currently need breakdown)

👀 Tracking

• FT-016 - Events Frontend (feature tracker with feature-tracker tag)
  • This tracker has spawned several child cards:
    • Event List Component
    • Event Detail View
    • Event Form Validation
    • Event Calendar Integration
    • Event RSVP Components
    • Event Reminder UI

🔜 Sprint Queue

• Event RSVP Components (child card - ready to pull into sprint)
• Event Reminder UI (child card - ready to pull into sprint)

Note: The first four child cards (Event List Component, Event Detail View, Event Form Validation, Event Calendar Integration) are already pulled into the current sprint and not shown in this 🌊 Pipeline Board view.

Cross-Team Child Cards:

Here's a useful pattern: child cards can be created in ANY team's pipeline, not just their parent tracker's space. This is particularly useful for deployment tracking.

Example: The FT-016 Events Frontend tracker spawns child cards for its work:

• Events UI Components → Frontend sprint
• Events Documentation → Frontend sprint
• Deploy to Staging → Infrastructure sprint (different team!)

The deployment card lives in Infrastructure's sprint, but the Frontend tracker shows its progress. This pattern works for both feature trackers and task trackers.

Feature Trackers vs Task Trackers in Team Spaces:

Team spaces accept both feature trackers and task trackers. Feature trackers come from the Unio Features board (after going through planning), and they represent substantial work that needs to be broken down into child cards. Task trackers are for tactical work that doesn't need the full planning process—they're created directly in the team pipeline when you have clear, straightforward work to execute.

What makes something a task tracker?

Task trackers are for work that's straightforward and doesn't need strategic planning. Think bug fixes, package upgrades, refactoring, infrastructure improvements, and small enhancements where you already know what needs to be done.

When to use task trackers:

Use a task tracker when the work:

• Needs no vision/requirements phase (approach is obvious)
• Is clear, tactical work with straightforward execution
• Involves mostly single-team execution
• Examples: bug fixes, package upgrades, refactoring, infrastructure tasks

Use a full feature when the work:

• Needs cross-team discussion or planning
• Has strategic impact on product or team workflow
• Involves user-facing changes affecting experience
• Examples: new capabilities, significant system changes, workflow improvements

Examples:

• Task Tracker: Fix login error on Safari - Bug affecting subset of users, clear reproduction steps
• Task Tracker: Security update for backend authentication package - Critical patch, single developer can tackle and deploy
• Task Tracker: Upgrade Zod package in frontend - Requires coordination and discussion, approach is clear
• Feature: Configure GitHub workspace rules - Strategic decision affecting team workflow, deserves planning discussion and communication

Creating and working with task trackers:

Task trackers follow the same pipeline workflow as feature trackers, but with one key difference: you create them directly in your team's 🌊 Pipeline Board instead of going through the Features board planning process.

1. Create a tracker card directly in your team's 🌊 Pipeline Board (in "📋 Needs Breakdown")
2. Set the relevant module as its parent (just like feature trackers)
3. Tag it with task-tracker
4. Add a brief description
5. Break down into child cards as needed and move to 🔜 Sprint Queue
6. Move the tracker to "👀 Tracking" once broken down
7. When all child cards complete, move the tracker to the 🚚 Shipped Board

The task-tracker tag helps with filtering and reporting—it makes these lightweight trackers visible so they don't become a backdoor around planning for work that actually needs it.

Real Example: Backend Task Tracker

📋 Needs Breakdown

• (empty - no task trackers currently need breakdown)

👀 Tracking

• Security Update - Auth Package (task tracker with task-tracker tag)
  • This tracker has spawned child cards:
    • Update auth gem dependencies
    • Run security tests

🔜 Sprint Queue

• Update auth gem dependencies (child card - ready to pull into sprint)
• Run security tests (child card - ready to pull into sprint)

The task tracker follows the same structure as feature trackers, just created directly in the 🌊 Pipeline Board. Like feature trackers, task trackers can also spawn child cards into other teams' pipelines if needed (for example, a deployment card to the infrastructure pipeline).

How granular should you go?

You decide how to break down work based on what makes sense for your workflow. Create as many or as few child cards as you need. Use checklists within cards for sub-items and validation steps. Mix and match: cards can have checklists, child cards, or even child cards that have their own children. There are no hard rules here—organize work in whatever way helps you execute effectively in your sprints.

Once you've broken down the work and populated your 🔜 Sprint Queue, you're ready to start pulling work into sprints.

Phase 3: Sprint Planning & Execution

Now we're into the actual delivery work. Every two weeks, you're pulling work from your 🔜 Sprint Queue and moving it through completion. This is where the rubber meets the road.

Sprint Planning (Every 2 Weeks):

You'll pull child cards from 🔜 Sprint Queue into the current or next sprint based on capacity and priorities. Sprint boards use status lists to show progress: To Do → Doing → Blocked → In Review → Done → Cancelled. Meanwhile, the feature tracker on the 🌊 Pipeline Board automatically shows rollup progress as its child cards move through sprints.

During the Sprint:

Your child cards move through the sprint workflow (To Do → Doing → Blocked → In Review → Done → Cancelled) as work progresses. Here's how to manage the different states:

• Use "Blocked" status when a card can't proceed due to dependencies or external blockers
• Use "In Review" status when work is complete and waiting for someone to review it (code review, document review, design review, etc.)

As you complete child cards, they automatically update the feature tracker progress on the pipeline board. If you don't finish everything in a sprint, don't worry—Superthread automatically rolls incomplete cards to the next sprint.

Eventually all the child cards will be done, and that's when you're ready for the final phase.

Phase 4: Deployment & Shipped Tracking

The final phase is all about getting work into production and tracking what's been delivered. This is where you close the loop on a feature.

When all child cards of the feature tracker complete:

1. Deploy the feature to production
2. Move the feature tracker from the Pipeline Board to the Shipped Board (each team has a separate Shipped Board)
3. Update the related Module card status if needed (for example, move it to "✅ V1 Ready" if this feature completes the V1 scope)

About Shipped Boards:

Each team space has its own 🚚 Shipped Board where completed work lives. This separation by team makes it easy to see what each team has delivered and enables team-specific reporting.

Using Shipped Boards for Sprint Reviews

The 🚚 Shipped Boards are particularly useful for biweekly sprint reviews. You can use Superthread Views (see Views documentation) to create cross-team sprint reports.

Potential View examples:

"Last Sprint Completed"

• Filter by: Completed date = last 2 weeks
• Include spaces: Frontend, Backend, Design, etc.
• Shows: Everything shipped across all teams in sprint period

"March 2026 Shipped"

• Filter by: Completed date = March 2026
• Include spaces: All team spaces
• Shows: Monthly delivery for management reporting

Team Workflows

Now that you understand how work flows through the system, let's look at how different team members interact with it in their day-to-day work. Different roles care about different levels of the hierarchy.

Product Manager

As a PM, you're mostly working at the strategic level—keeping track of what's being built and what's coming next.

Your daily workflow typically involves:

• High-level view: Check the Domains board for overall progress across the platform
• Detailed view: Check the Modules board to see what's "⚙️ In Progress" vs "✅ V1 Ready"
• Filtering: Use main-app and portal-app tags to see portal vs main app progress
• Timeline views: Use Superthread's Gantt charts for management reporting
• Sprint reviews and monthly reporting: See Phase 4 for Views setup

Developers & Designers

As someone who's building and delivering work, you're focused on execution—understanding what needs to be built, breaking it down, and delivering it.

Your workflow typically looks like:

• Start your day by checking your team's current sprint for work to do
• Participate in vision and requirements phases for most features (we value your input early)
• Contribute to spec and planning phases as needed (you won't be in every feature's planning, just the ones relevant to you)
• Break down feature trackers on your team's pipeline board (see Phase 2)
• Execute work in sprints (see Phase 3)

Using Tags

Tagging Strategy

We have a few established global tags that we use consistently:

• App context: main-app, portal-app (or both if applicable)
• Card type: feature-tracker (for feature tracker cards on pipeline boards), task-tracker (for task tracker cards on pipeline boards)

Feel free to use tags however you want in your own space—tags you create are unique to your team and won't clutter other teams' tag lists. If you think a tag would be useful globally, just talk to the team and we can add it to our shared tagging strategy.

Tags let you filter across boards and create Views for reporting.

You're All Set!

Now that you understand the Unio workflow, you have everything you need to work on Unio with confidence. Whether you're planning features, breaking down work, or tracking progress through sprints, you know how everything connects and flows together.

The beauty of this system is that it scales with you—from high-level strategic planning down to your daily work. You can dive deep into the details when you need to, or step back for the big picture view. And as our team grows and our needs evolve, the workflow adapts right alongside us.

Ready to get started? Pick up your first feature card, create that first feature tracker, or dive into your current sprint. You've got this.