After following the guidelines in Stage 3, you’ll have a clear roadmap for your product launches.
This can work as a framework to break your project down into small pieces, schedule sprints, and understand what kind of resource allocation you need to launch your project on time.
You’re reading stage 4 of Airtable’s guide for product operations
Explore the full stage here
Follow along in Airtable.
In this step, we’ll explore this team-level template. Dive deeper into the product operations workflow here.
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:
Download and customize the template featured in this video here
⚡ Pro tip
“Retrospectives” can also be a separate table instead of a field within the “Sprints” table, if you want to solicit retrospective feedback via forms or do more fine-grained analysis. You can even set up a recurring automation to remind team members to add their retrospective notes.
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.
Include additional fields in the tables mentioned above, like an attachment field, so you can embed the specific assets that need reviews and approvals.
Create an attachment field
Try it in you base now
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.
Create a button field
Try it in your base now
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:
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.