R&D Board — Product Development#

The R&D board is Lifecycle OS's most powerful board type. It's built for engineering and product teams who need more than a basic task list — a full system for planning, executing, tracking, and shipping software.

From idea capture to production deployment, the R&D board handles the complete product development lifecycle. Sprint planning, QA workflows, design status tracking, stage-based deployments, and release management are all built in. No plugins. No workarounds.

Who It's For#

The R&D board is designed for teams running scrum or a scrum-adjacent process. If your team does sprint planning, story pointing, development + QA cycles, and staged deployments, this board was built for you.

Tip: If your team doesn't run scrum — or if you just want a simpler task board — start with a Custom board and build the workflow you actually use.

Work Item Hierarchy#

The R&D board uses a three-level hierarchy: Story → Task → Sub-task.

Stories#

Stories are the top-level unit of work — a feature, improvement, or change to be built. Stories describe what you're delivering and why. They're the items you'd typically present in a sprint review or include in release notes.

Stories carry the high-level context: priority, assignee, epic, pipeline status, design status, estimated scope.

Bugs#

Bugs live at the same level as stories — they're top-level items, not children of stories. A bug is a defect discovered in production or testing that requires its own tracking, prioritization, and resolution workflow.

Tasks#

Tasks live under stories and bugs. They're the units of execution — the specific development, review, or integration work required to complete the parent story. A story might have 3–10 tasks. Each task has its own assignee, estimated hours, QA assignee, QA hours, and stage.

Tasks are what your developers are actually doing day to day.

Sub-tasks#

Sub-tasks live under tasks. They're granular, checklist-style steps for complex tasks that benefit from breakdown — individual API endpoints, UI components, test cases. Sub-tasks are optional; use them when a task is complex enough to warrant it.

Pipeline Stages#

The pipeline is the planning workflow for stories before they move into active development. Stories flow through pipeline stages as they get defined, refined, estimated, and approved.

Review#

The entry point for new stories. Raw ideas, requests, or early drafts land here. The team reviews whether the item is valid, clearly defined, and worth pursuing.

Backlog#

Stories that have been reviewed and accepted but aren't scheduled yet. The backlog is the team's inventory of future work.

Refinement#

Stories that are being actively defined. The team is writing acceptance criteria, breaking down scope, resolving open questions, and getting the story ready for estimation.

Estimation#

Stories ready for story pointing or hour estimation. The team has enough clarity to estimate effort.

Ready#

Estimated stories approved and ready to be pulled into a sprint. These items are fully defined — development can start without needing additional clarification.

Completed / Cancelled#

Terminal pipeline states. Completed stories have shipped. Cancelled stories were deprioritized or invalidated.

Customizing the Pipeline#

The six stages above are the default pipeline. You can adjust them to match your planning process.

How to customize: Open your board → click the gear icon → Pipeline tab. You can enable or disable stages, reorder them, and configure which ones are active for your board.

20 Statuses Across 5 Groups#

Status tracks where a work item is in its execution workflow — independent of the pipeline stage. Statuses are organized into five groups.

Development#

Deployment#

QA#

Blocked#

Terminal#

Customizing Statuses#

These 20 statuses are the defaults — you don't have to use them all. Enable only the ones that match your workflow and disable the rest.

How to customize: Open your board → click the gear icon → Statuses tab. From here you can:

• Toggle individual statuses on or off per board
• Reorder statuses within each group
• Each board can have its own status configuration — your R&D board and Bugs board don't have to use the same set

Tip: Most teams start by disabling statuses they don't need yet. You can always enable them later as your workflow matures.

Built-In Fields#

These fields are built into every R&D board and cannot be removed:

Configuring Built-In Fields#

Not every team needs every field. You can enable or disable built-in fields per board to keep the interface focused.

How to customize: Open your board → click the gear icon → Fields tab. Toggle any built-in field off to hide it from views and forms. Toggle it back on when you need it.

Default Custom Fields#

These custom fields are pre-configured on every new R&D board. They can be renamed, reordered, or removed, and new ones can be added at any time.

These custom fields are a starting point. You can rename them, add new options, change colors, remove ones you don't use, or create entirely new fields.

How to customize: Go to Settings → Fields to manage all custom fields for your organization. You can also access field settings through your board's gear icon → Fields tab.

Default Views (15+)#

Every R&D board is created with a comprehensive set of views so your team can get to work immediately.

These views are pre-built to cover common workflows. You can edit any of them, create new ones, delete ones you don't use, or duplicate a view as a starting point for something custom.

How to customize: Click the gear icon on any view to open its settings. Adjust the display mode, grouping, sorting, visible columns, and filters. Or click + New View in the sidebar to start from scratch.

Dual-Track: Development and QA#

QA is a first-class citizen in the R&D board. Development and QA tracking are parallel tracks — not sequential steps.

Each task has:

• A developer assignee + QA assignee — different people, tracked separately
• Estimated hours for development + QA estimated hours tracked separately
• QA-specific statuses that run in parallel with development statuses

This means your QA team has full visibility into the queue, can plan their capacity, and doesn't need to wait for developers to hand off a spreadsheet. QA work is visible, measurable, and planned — not an afterthought.

Design Workflow#

Stories have a parallel design status field that tracks design work independently of development:

• Pending — Design work hasn't started
• Working on it — Design in progress
• Completed — Design approved and ready for implementation

Design status lives on stories, not tasks. This lets you filter and view stories by design readiness — a critical signal for engineering teams waiting on specs.

The Design View shows all stories with their design status, making it easy for PMs and designers to see where design work is blocked.

Stage Tracking: Predev → Dev → Production#

Tasks track which deployment environment they've been tested and deployed to:

• Predev — Development/internal testing environment
• Dev — Staging/QA environment
• Production — Live environment

Stage-specific deployment statuses (Pending Predev Deploy, Pending Dev Deploy, Pending Production, Production Deployed) let your team see exactly what's waiting to ship and where.

The three deployment views let release managers see everything queued for each environment at a glance.

AI Agent: Story and Task Generation#

The R&D board includes an AI agent that generates structured work items from natural language descriptions.

Give the AI a brief description of what you're building — a paragraph, a Slack message, a user story — and it returns a structured story with tasks broken down, estimated complexity, acceptance criteria, and relevant fields populated.

Use it to:

• Break down a feature description into a sprint-ready story with tasks
• Generate tasks from an existing story description
• Draft acceptance criteria for a rough idea
• Create a set of stories from a product brief

Tip: The AI agent is fastest when your description includes context on scope, user impact, and technical constraints. The more specific your input, the more accurate the output.

Sprint Integration#

The R&D board has full sprint management built in:

• Create sprints with start and end dates
• Add items to sprints individually or in bulk
• Sprint capacity planning — see estimated hours vs. team capacity
• Sprint board — kanban view of the active sprint
• Sprint reports — velocity, completion rate, carryover
• Burndown tracking — see progress against the sprint goal in real time

Sprints are optional — you can use the R&D board without running sprints if you prefer a continuous flow model.

RICE Scoring#

The R&D board supports RICE prioritization scoring via custom number fields:

• Reach — How many customers does this affect?
• Impact — How significantly does it affect them?
• Confidence — How confident are you in your estimates?
• Effort — How many person-months will this take?

RICE Score = (Reach × Impact × Confidence) / Effort

Add the RICE fields to your board, fill them in on stories, and use the RICE Score computed field to sort and prioritize your backlog. Groups with the highest RICE scores rise to the top.

Related#

• Understanding Boards
• Bugs Board
• Workspaces
• Sprint Management
• Custom Fields
• Understanding Views
• Time Tracking
• AI Agent