Integrating Airtable with Jira for Streamlined Project Management: The Features Table

Introduction

In the fast-paced realm of agile product development, the challenge often lies in communicating complex project details in a way that's accessible to everyone involved, not just the development team. That's where the magic of integrating Airtable with Jira comes into play, and it's what this blog series is all about.

The reason we've turned to Airtable for stakeholder reporting is simple: clarity and accessibility. While Jira excels in managing project intricacies, it can be a maze for stakeholders who need a quick, clear overview without getting bogged down in the details. Airtable, with its intuitive interface and customizable views, translates Jira's complexity into straightforward, digestible insights. This means stakeholders get exactly what they need: a real-time, simplified snapshot of project progress, feature development, and key milestones, without the need to wade through Jira's more technical aspects.

This series will walk you through how this integration not only streamlines our project management but also revolutionizes stakeholder communication, ensuring everyone stays informed and engaged throughout the product development cycle.

Glossary

Before we dive into the specifics of our feature table, it's important to understand the two tools we're integrating: Airtable and Jira.

• Airtable: A cloud-based collaboration tool that combines features of spreadsheets and databases, allowing for highly customizable data organization and visualization.
• Jira: A project management tool used predominantly by software development teams for issue tracking, sprint planning, and backlog management.
• Epics: Large bodies of work in Jira that can be broken down into smaller tasks or issues.
• User Stories: Simple feature descriptions from the perspective of the end-user, typically formatted as: "As a [type of user], I want [an action] so that [a benefit or value]".
• Grooming (or Backlog Refinement): The process of reviewing and adjusting backlog items to ensure they are clear, concise, and actionable.
• Bugs: Errors or flaws in the software that need to be fixed.
• Issues: A term used in Jira to denote tasks, bugs, or user stories that need to be worked upon.
• Sprints: Defined periods during which specific work has to be completed and made ready for review in agile development.
• Story Points: A unit of measure used to estimate the effort required to implement an issue based on its complexity.

For more reading, see

Unpacking Jira Terminology: Epics, Stories, Bugs, Tasks, and Issues

Sources of Truth

A "source of truth" is a term used in information management to describe the authoritative data source for a given piece of information. In the context of project management and specifically in managing a feature development process, having a source of truth means having a central place where you can look at to get the most accurate, up-to-date information about the features you are working on.

It's essential that your overall plan in Airtable reflects the most recent issue data from Jira for several reasons:

1. Accuracy: Having the most recent data ensures that what you're seeing and working with is accurate. This is crucial for making informed decisions about your projects. If the data is outdated, the decisions made based on that data may no longer be valid.
2. Efficiency: It saves time and reduces the risk of errors. If data is manually updated, there's a chance that something could be missed or entered incorrectly. By syncing the data directly from Jira, you're eliminating those risks and ensuring that the data in your Airtable base is always up to date.
3. Collaboration: When everyone on the team has access to the same, most recent data, it improves collaboration. There's less risk of misunderstandings or miscommunications about the status of different tasks and projects. This can lead to increased productivity and better results for your team.
4. Trust: Lastly, having a single source of truth builds trust within the team. When everyone knows that they can rely on the data in the Airtable base to be accurate and up to date, it builds confidence in the team's processes and decision-making.

Hence, syncing the latest issue data from Jira to Airtable, allows Airtable to serve as this "source of truth", ensuring that your team always has the most current and accurate information at their fingertips.

The Feature Table

The “feature” table in my airtable base serves as a central repository for all information related to a product's features. This table, powered by the seamless integration of Jira and Airtable, enables us to have a snapshot view of our product's roadmap at any given moment.

These fields get synced from Jira to Airtable

1. Issue Key: The unique identifier for each issue in Jira.
2. Reporter: The person who reported or created this issue.
3. Summary: A brief title description of the feature or task at hand.
4. Issue Type: The type of this issue, such as "Bug", "Story", "Task", “Epic” etc.
5. Description: A detailed description of the feature’s product requirements, which are stored in jira
6. Status: The current status of the epic (New, Discovery, Needs Grooming, Ready, In Progress, Under Review, Approved, or Closed)
7. Labels: similar to tags in other systems, labels are a flexible way to categorize issues in Jira
8. Assignee: The person currently responsible for this issue.
9. Priority: The urgency of this feature or task, typically defined as "Low/Nice to have", "Medium", "High", or "Urgent/Critical".
10. Phase (aka fix version): The release phase that an epic or issue is expected for release.
11. Last Updated: The date when this epic was last updated.
12. Created: The date when this epic was created.

Additional Fields in Airtable

While Jira offers a robust set of issue tracking capabilities, there are additional elements of our feature management process that don't map directly to Jira fields. To track these, we've created custom fields in our Airtable table. These fields capture crucial aspects of the feature lifecycle that are unique to our team's workflow or otherwise don't exist in Jira.

Let's discuss these fields in detail:

1. Positioning Statement: This field captures the marketing positioning statement for the feature. It helps in aligning the product and marketing teams on how the feature should be positioned in the market.
2. Discovery Start (Date): This field records the date when the discovery phase for the feature begins. The discovery phase is when we explore and define the requirements of the feature in detail.
3. Grooming Start: This is an important part of our development process, as it is when the team reviews the feature requirements and starts breaking them down into manageable tasks.
4. Target End Date: This field stores the projected end date of the feature development process. This helps in tracking the progress of the feature and ensuring that it is on schedule.
5. Target UAT Date: The Target User Acceptance Testing (UAT) date is a crucial milestone in our development process. It signifies when we expect the feature to be ready for final testing by the product team.
6. Target Launch Date: The expected date when the feature will be released to our users. This field helps us in planning our product roadmap and aligning it with the business objectives.
7. High-Level Estimate (T-Shirt Size): To provide a quick, high-level estimate of the effort required for a feature, we use a T-Shirt size estimation method (Small, Medium, Large, X-Large). This is a simple way to gauge the complexity and size of a feature without getting into detailed planning.
8. New Feature Tech Assessment Complete (Checkbox): This checkbox indicates whether a technical assessment has been completed for a new feature. This is a crucial step in our process, where we determine the feasibility of the feature from a technical perspective.
9. Handed off to Design (Checkbox): This checkbox is marked when the feature has been handed off to the design team. This is a crucial step in our process, as it signifies the transition from planning to the design phase.
10. UX Priority: The priority of the feature from a user experience (UX) perspective. This helps the design team in prioritizing their work.
11. Ready for Design Presentation (Checkbox): This checkbox is marked when the feature is ready to be presented to the team by the design team.
12. Design Presentation Complete (Checkbox): This checkbox is marked when the design presentation has been completed.
13. Handed off from Design to Engineering: The date when the design team hands off the feature to the engineering team.
14. Grooming Start: This field indicates the date when we begin the grooming process for the feature. Grooming is the process of refining our backlog items, ensuring they are clear, concise, and actionable.
15. Ready for Product Kickoff (Checkbox): This checkbox signifies whether a feature is ready for the product kickoff meeting. This meeting marks the official start of the feature development process.
16. Product Kickoff Complete (Checkbox): This checkbox is marked when the product kickoff meeting has been held.
17. Content Requirements: Any specific content requirements for the feature. This could include user interface text, documentation, or marketing materials.
18. Content Status: The current status of the content development for the feature. This could be "Not Started", "In Progress", "Review", or "Complete".
19. Linked Issues: This is a field in Airtable that connects each feature in the "Features" table to the related issues in the "Issues" table. This is a Linked Record field that connects each feature in our "Features" table to the related issues in our "Issues" table. I use an automation trick to make sure that all of my records in the "issues" table are linked to the correct epic in the "features" table because this allows me to use rollup fields and count fields to calculate the other values.
20. Count Issues: This field counts the number of issues linked to each feature. It's a Count field type in Airtable that operates on the Linked Record field "Linked Issues".
21. Count Issues Groomed and Ready: This field would typically count the number of issues that have been groomed and are ready for development.
22. Count Issues without Story Points: This field counts the number of issues that have not yet been assigned story points, which are often used as a measure of the effort required to implement an issue.
23. % Issues Groomed and Ready (Progress Bar): This field calculates the percentage of total issues that are groomed and ready for development, often represented visually as a progress bar.
24. Count Issues Sprinted: This field counts the number of issues that have been added to a planned a sprint, a defined period of time during which specific work has to be completed and made ready for review.
25. % Issues Sprinted (Progress Bar): This field calculates the percentage of total issues that have been included in a sprint, often represented visually as a progress bar.
26. Total Story Points: This field sums up the total number of story points that have been assigned to issues linked to a feature.
27. Story Points Complete: This field sums up the total number of story points that have been completed. This is typically based on the issues that have been marked as complete and the number of story points that were assigned to them.
28. % Story Points Complete: This field calculates the percentage of the total story points that have been completed.
29. % Issues Complete: This field calculates the percentage of total issues that have been completed.

This integration between Airtable and Jira epitomizes our commitment to efficient, transparent, and inclusive project management. It's a testament to our approach in keeping everyone, from team members to stakeholders, aligned and informed, ensuring a smoother path from concept to completion.