Get started

CROWeekly: Reducing Project Data Bloat

What Happened at Corvus CRO Last Week

screenshot of a Kanban board
A Kanban board display we use for managing split tests

How Corvus CRO Manages Split Tests Efficiently

We use a Kanban board view in Airtable to monitor and manage experiments. Each experiment is an Airtable record, which translates to a card on the board. There are 5 channels for progress stages of an experiment life cycle:

Moving a card from one channel to another triggers automation for repeatable tasks like sending status notifications, running a report, or updating project information. We use Basecamp for project management, but this process can be applied to almost any project management platform that has API, like Asana, Jira, or Trello. The automation is set up to use API hooks for performing simple, repeatable, standardized processes like creating projects/tasks, adding notes, and assigning tasks. This significantly cuts down on overhead and eliminates a lot of tedious manual configuration drudgery from the project management process.

screenshot of a Kanban board
Our split testing project list was becoming a bit bloated

Updating Our Process to Reduce Data Bloat

The goal of any good project management process is to minimize overhead. One important component of project management is dealing with data bloat. A lot of project data has a shelf life; it’s relevant and useful for only specific period of time. Data bloat accumulates when tasks aren’t acted upon and data goes stale. As data piles up, it becomes harder and harder for users of the system to find relevant information quickly and actually get work done. This wastes time and causes frustration. Worse, information bloat can lower morale if ignored for too long. To help combat data bloat, we’re making a change to our project creation automation.

Previously, we had the automation set to create a new project for an experiment when it was moved into the Planning stage. A lot of projects were getting created. Projects for lower priority experiment ideas were just sitting open and unused, making it harder to find the active projects. Sometimes an experiment idea would be scrapped or modified before it  was ready to build. If a project had already been opened for that experiment then it had to be manually updated, creating unnecessary revision work.

Now the automation creates projects when an experiment idea progresses to the Build stage. Building an experiment is where the bulk of actionable tasks begin, so this change should help increase project data freshness. Projects will be created more closely to their “ready for work” state instead of sitting open and unattended. The tasks that go on during the planning stage have been migrated to a separate, repeatable weekly task.