If you have a car, maybe you’ve noticed a trapezoidal port underneath your steering wheel. This is the car’s diagnostics port (more specifically, it’s the On-Board Diagnostics port, or the OBD-II); every car built since January 1, 1996 is required by U.S. law to have one. Through the OBD-II port, mechanics are able to monitor the car’s chassis, body, accessory devices, and diagnostic control network.
Automatic Labs, headquartered in San Francisco, has made it their mission to take all this information hidden away inside your car, previously only available to professional mechanics (or serious gearheads), and to make it accessible to the average consumer. With Automatic’s matchbox-sized OBD-II adapter, your smartphone, and their free app, you can see all of your car’s diagnostics for yourself — including your mileage, gas usage, performance, and engine health. If your check engine light turns on, Automatic can diagnose your car’s problem right away and let you know if the issue is something you can fix yourself — like a loose gas cap — or, if the issue is more serious, give you the locations of nearby car mechanics.
But Automatic does more than just help you monitor and resolve your engine’s health issues — it uses the full power of the internet and your smartphone to turn any car into a connected car. For example, Automatic will alert emergency services and your loved ones if you get into a serious car accident. You can also use Automatic to help you save money: Automatic’s adapter has a built-in speaker and can be set up to give you real-time driving feedback to maximize your fuel efficiency. The Automatic app can even tell you where you last parked your car.
Automatic envisions a world in which all drivers are smarter and more informed about how they drive. To that end, they’re regularly adding new features to their product, in a way that requires a focus on the rapid iteration cycles and continuous improvements of agile software development. In order to manage their product development effectively, they’ve created an Airtable base that’s generally structured around agile principles, but they’ve also crafted their base in such a way that it’s perfectly tailored to the unique quirks in their product management style.
Keeping their stories straight
Automatic uses several different interrelated concepts from agile software development to think about how to translate customer needs into a better product. One common way in which agile developers do this is by translating every customer need into a story — a brief, high-level description of a user’s specific requirements, written from the perspective of a user. These stories are the basic units used to structure product planning. The purpose of thinking about product development in terms of stories is to make sure that the customers’ desires are always foregrounded.
Accordingly, the heart of Automatic’s Airtable base is the Stories table, which is also by far the largest of their base’s tables. In the Stories table, each story gets its own record. One story might be “S132: Audio tone when adapter detects presence of ghosts” or “S142: Improved graphics on time travel analytics dashboard.” To see how each of their stories fits into the greater scheme of Automatic’s product development, each story record is linked to the Epics table, the Sprints table, and the Facets table using Airtable’s linked record fields.
An epic is an amalgamation of many related user stories together — so, for example, the stories “S137: Ability to trigger giant robot transformation sequence remotely” and “S138: Change progress bar graphics for giant robot transformation sequence” might both be part of the epic “E117 — Robot transformation sequence.”
A sprint is when a team works to complete a group of user stories in a set amount of time (usually a few weeks). Each of Automatic’s sprints in their Sprints table is named after a model of car — so, for example, they might have a goal of completing 10 stories during the Ferrari 500 sprint, and each of those 10 stories is linked to the Ferrari 500 record in the Sprint table. Additionally, they have categories called Icebox — Someday and Backlog — Required for stories that aren’t a part of any particular sprint, but that they want to build at some as-yet-undetermined point in the future.
Facets aren’t a standardized element of the agile software development lexicon, but Automatic uses the term facets to mean broader components of the product. An example of a facet might be Device Connection or App Settings.
With all of Automatic’s stories, epics, sprints, and facets linked together, it’s easy for their team members to see how each of the stories they’re working on fits into the bigger picture.
Automating Automatic with formulas
The code for each story’s record is automatically generated using a formula field which takes the contents of an autonumber field called story_id, adds an “S” to the beginning, and concatenates that with the text of the User Want field.
Since they only need to use story_id to generate numbers for the codes and they don’t need to look at it otherwise, they keep story_id hidden.
In addition to using formulas to generate names for their records, they also use a formula field to automatically generate URLs. Automatic uses Phabricator, a tool for software development collaboration, to manage each of the tasks associated with their stories. Every URL on Phabricator is built according to a set format. If you have the number Phabricator assigns to your task, you can reconstruct the URL — which is exactly what Automatic does with their PhabURL field. If the number field PhabTask in the Stories table contains the story’s appropriate task number, then the PhabURL field concatenates the task number with the right URL prefix to make a working link. With this field, anyone looking at the story in the Airtable base can quickly click the link in the PhabURL field to get to the appropriate task in Phabricator.
Creating a list of priorities
To make it easier and faster for team members to add new stories, Automatic has set up an Airtable form that will automatically create a new record in the Stories table from the submitted information.
When new stories are entered into the table, they’re not necessarily entered in order of when they need to be completed, and with over a hundred stories and counting, it’s critical to be able to see at a glance which stories are the highest priority. Fortunately, Automatic has created a system for quickly seeing which stories most urgently need their attention.
The Release Milestones table has a list of all of Automatic’s upcoming big releases, numbered in the order in which they need to be completed. For example, all the stories linked to the Beta1 release milestone need to be completed before the stories associated with Full Release, so Beta1 gets a lower number in the Sequence field than Full Release.
Meanwhile, on the Stories table, the Blocks Release linked record field shows which of the release milestones each story is blocking. A lookup field called Release Seq No then uses the links in the Blocks Release field to bring the sequence number of each story’s associated release milestone into the Stories table. Then, by sorting by the Release Seq No field, it becomes easy to see which stories need to be completed before other stories.
And what about the stories that aren’t dependent on any other releases? Automatic has a neat trick for this — the Release Milestones table has a record called No Hard Requirement, with an associated release sequence number of 100. This way, any stories that can be completed independently of other stories will automatically be pushed down to the bottom of the list when arranged by release sequence number.
Counting the stories
With the sheer number of linked record fields and linked records therein, Automatic has found it helpful to create a few count fields in order to know just how many stories they need to complete for each of their larger goals. In the Epics table, there’s a count field which counts the number of stories that have been linked to each epic, and therefore how many stories each epic holds; in the Release Milestones table, there’s a count field which counts the number of stories that have been linked to each release milestone, and therefore how many stories need to be completed before they can pass another release milestone.
Agile estimation techniques in Airtable
Before getting started on any work, the product team takes the time to estimate how much work each story will take on the server side and the client side. Like many agile teams, they use a scale based on the Fibonacci sequence for their estimations, where stories marked 1 and 2 are those requiring relatively few work hours and 8 and 13 are the most time-consuming. They put their estimations in the Server Points and Client Points single select fields, respectively.
On the Epics table, they use rollup fields to estimate just how labor-intensive each epic will be overall, taking into account the estimated Fibonacci numbers for each story. The Server Pts and Client Pts rollup fields look at all of the stories linked to each epic, take the points from each story’s estimations in the Stories table, and add them up. This way, it’s easy to see at a glance which epics are likely to be the most time-consuming to complete.
The product team also gets feedback from the developers on how labor-intensive — or not — they think completing each epic will be. On the Epics table, there’s a single select field called RobEst, in which Rob Ferguson, the VP of software engineering at Automatic, assesses each epic on a T-shirt sizing scale going from XS to XL (or even XXXL).
Agile software development values continuous improvement and flexibility. This means that Airtable, an endlessly flexible tool for organizing and planning, is a great fit for an agile team. While Automatic’s product team likes to use the Fibonacci sequence to estimate their workload, engineering likes to use the T-shirt scale. Since Airtable makes it easy to add and tweak new fields, Automatic’s base can support both the product and engineering teams’ preferred methods. Furthermore, Automatic has created a custom base which supports their own unique variations on the standard agile processes — the standard stories, epics, and sprints of agile development can coexist with the quirkier facets. With Airtable, instead of forcing your team to conform to a predetermined workflow, you can build up an Airtable base that works the way your team wants it to.
Special thanks to Adam Altman, the head of product at Automatic Labs, for sharing Automatic’s best practices for agile product management with us! You can reach him on Twitter, @a18n.