Step 4.1: Start managing sprints and product delivery

Define delivery information

To manage sprints and ongoing delivery, the first step is to define information for the tables we’ll be working from.

While every product team has its own terminology and will want to track different information for ongoing product delivery, many use some variation on projects, sprints, and tasks:

• Projects (or features or epics) are your main unit of work. Projects can be broken down into tasks or user stories, and include details like cross-functional owners (for resource allocation) and related assets (like product requirements documents and design files). 

• Sprints (sometimes referred to as an “iteration”) are defined periods of time (often 2 weeks) where a development team works to complete specific tasks or milestones. 

• Tasks are the smallest unit of work. Ideally, a task should be able to be completed within a sprint. They are broken down from Projects, and they are what we will be tracking in ongoing sprints. Many times, tasks are synced from a system such as Jira–we provide integrations to tools like Jira Cloud, Jira Server/Data Center, Github Issues, and more.

Watch this video to see some commonly used fields for managing sprints and tasks:

Provide additional project information and requirements

Context is key—especially when you start sending out assignments (and deadlines). Below are a few ways you can relay a ton of critical information that might live in different documents. 

1. Attachments:

Include additional fields in the tables mentioned above, like an attachment field, so you can embed the specific assets that need reviews and approvals.

2. Buttons:

We also often see customers utilizing the button field, which lets you create direct links to assets in your base, like PRDs and associated Slack channels. Consider adding a single select field next to the button to note the status of the asset (i.e. “not started,” “in review,” “approved,” etc.) to keep stakeholders informed.

Break projects into individual tasks

Once you’ve set up your tables, it’s time to break projects down into smaller tasks, which can then be assigned out.

You might start by connecting Airtable to the existing data sources your teams use for task tracking, and associating them with specific projects. For example, many engineers use Jira or Github Issues for user stories or bug reports. By connecting Jira to Airtable with an external source sync, you can track the work engineers are already doing, right in your base.

When you import records from Jira and link them to the appropriate projects/features in Airtable, product owners can see the most up-to-date info as engineers update dates, statuses, and more. And you can easily click through to a Jira ticket from any task in your base.

And still another suitable option is to break projects down into specific user stories, product backlog items, or sprint tasks—typically a joint effort between product teams and engineering. Then, user stories can be broken down into smaller sub-tasks with their own associated assets, like:

• Design

• Code

• Tests

• Documents

• UX polish

• Fixes

With the backbone of your sprint management system in place, make sure everyone involved in ongoing delivery has the right information to check their tasks off the list. We’ll show you how in the next step.