Confluence Databases for Project Tracking
Keeping track of all the pieces of a project can be challenging. Fortunately, there are a ton of different tools out there to get the job done. Recently, however, I’ve been using Confluence Databases to see how this feature can help me track project work, and I’ve found it to be pretty good at handling small to mid sized projects.
What is it?
Confluence Databases sit somewhere between a table/spreadsheet and Jira. They live in the content tree of a Confluence space, and look similar to a table. That is where the similarity ends though, as they have a number of functions that are very useful in tracking project statuses. This includes things like tracking specific users, linking to Jira tickets or Confluence pages, and even linking to other tables.
Features that help project managers
There’s a few specific features that I’ve found make a database very useful to project managers.
Saving (and easily sharing) filter views is incredibly useful. This allows me to create a view once, then share it with specific groups. I could, for example, share a list of new tasks with analysts so they can build out specs, or a list of blocked items to bring up at the start of our calls. Since the filter is saved in the URL this is as easy as copying/pasting, and can be bookmarked.
The native integration with Jira is another great feature as it’s highly likely I’ll be using Jira if I’m in Confluence. Being able to link a line in my database with 1 (or more) Jira tickets lets me keep my developers in Jira while still giving me easy access to what’s going on in there. This allows me to easily give my stakeholders a view of the project that isn’t too “technical” while preserving direct links to more information in case they want it.
Finally, configurations can be copied into a new database. This lets me easily make a clean copy of the database for a new project and preserve all of the columns and other settings I have. This means that once I have a good structure in place I can make as many copies as I need to, slot them into the proper place of Confluence, and not have to worry about deleting anything.
Database Setup
I’ve been using Databases to track relatively simple projects, so I added in a number of basic fields:
Task Name - A text field containing the name of the task
Status - A Tag field indicating the status (To Do, Blocked, etc) of the task
Owner - A User field with the task owner
Due Date - A Date field with when the task is due
Jira Ticket - If the task has a jira ticket it’s linked here
Jira Ticket Details - The assignee of the linked Jira ticket
Documentation - A link to any Confluence pages with more information
Why not just use Jira ?
There is an interesting question of why wouldn’t I just have used Jira to track my project work. There’s a few reasons:
Trying something new - I find it’s really important to expose myself to new ideas, tools and methodologies. Not only will this give me more options for managing projects, but I might find something useful that can be applied elsewhere.
Light weight - Setting up a Jira project takes time and sometimes requires a Jira admin to help with setup and changes. Both of these things may be in short supply, so having an option that is more robust than a spreadsheet (which may be flexible, but lacking features), but less heavy than a full-on Jira project is very attractive.
Presentable - I’ve found that many stakeholders don’t like going into Jira to get information on how things are going. Having another option, like an easily-accessible page in Confluence, has been great as people actually use them.
Flexible - The ability to easily add new columns, save filter-views and share information quickly makes databases very attractive. It hardly takes any time to add or adjust data, making it easy for my team to keep things up to date.
Integrations - Being able to instantly connect Confluence pages and Jira tickets makes Database more data-rich. For example teams can easily see any related Jira tickets, and stakeholders can easily access documents from one spot.
Why not just use a spreadsheet?
Spreadsheets are a great tool for many things, and they’re incredibly flexible. This makes them the go-to for many project trackers, especially if they don’t need specific features or integrations. That said, use a Database has a number of advantages:
Everything in one spot - If you’re already using Confluence you’re likely storing other project documentation in there as well. Having a database to track your progress puts everything in one spot, in the same system. This reduces the administrative overhead needed to track, maintain and manage things, and also leads to
Integrations - Aside from the built-in integrations with Jira, having your plan in Confluence makes it a lot easier to reference on other pages, integrate with other information and make more easily available.
Presentable - Similar to #3 above, I’ve found a database is easier to share with others, and easier for them to interpret. While a spreadsheet may have all the info in there, it’s easy for someone to go to the wrong tab, workbook, etc. and get frustrated.
Re-use - The configuration of a database can be copied into a new database in a few clicks. This makes it incredibly easy to spin up new projects with the same setup as an old one. A spreadsheet would require copying, then deleting everything to start over.
Final Thoughts
Databases are a great mid-weight way to track projects. The biggest hurdle for me was just figuring out what fields to include and after that I found them easy to update and use. Will they entirely replace spreadsheets? No, however, they do give project managers another great option to keep things on track.
