An agile product roadmap is never static. New technical requirements, business needs, stakeholder feedback, customer input, and unplanned work can all change what your roadmap looks like. For some product managers, understanding the implications of roadmap changes and communicating them to stakeholders can waste a lot of valuable time. That’s exactly what Carl DiClementi, Director of Product Management at Factom, wanted to avoid when he began his new role. Factom is a B2B blockchain solution that helps companies with data assurance. They provide a collaborative platform to preserve, ensure, and validate digital assets.
The problem with keeping product roadmaps in spreadsheets
For years Carl had maintained his roadmap in spreadsheets. While spreadsheets can be helpful for some elements of product roadmapping, he discovered that they don’t scale and they’re time-consuming and tedious to keep up-to-date. Carl said, “I was very tired of being an Excel master. I didn’t want to spend half my week updating my roadmap in Excel based on whatever had happened in Jira Software.” In his previous role, he switched to Portfolio for Jira to help with this problem. Accordingly, one of the first things he did when he started his role at Factom was to implement Portfolio.
Carl explains one of the primary reasons he prefers to keep his roadmap in Portfolio for Jira: “Of course we all try to avoid it, but sometimes an effort gets resized; this could be due to new customer requirements or if the tech team unearths a roadblock. At that point, most often, everything after gets pushed back. With Portfolio for Jira, it’s really easy to update my roadmap and see what’s moving and what my new delivery dates are. I don’t have to resize work items in Jira Software and then go into another tool to calculate what needs to move. Those days of spreadsheet hell are over.”
How Factom uses Portfolio for Jira for quarterly planning
Portfolio for Jira has become an integral part of the way that Carl plans, communicates with stakeholders, and gets better visibility across what’s happening in Jira Software. He plans one quarter in advance. To start his quarterly planning process, he’ll sketch a couple “programs” with rough estimates. “Programs” are a level of hierarchy Carl has created above epics (Portfolio for Jira enables you to create unlimited levels of hierarchy above epics) which he defines as “high-level and time-bound.” He documents all his programs on a Confluence page, which he shares with business stakeholders and then collects requirements from them. After gathering business requirements, he works with his engineering team to break down work into epics and stories with the help of the technical team.
Once everything is successfully broken down, Carl gets a clear overview of the team’s epics and stories inside of Portfolio for Jira’s scope table. This is where he massages prioritization and also adds labels and story points in case they aren’t there. According to Carl, he prefers Portfolio for prioritization because “it helps to understand the impact of ranking one issue above another in the backlog, and how this will affect the roadmap across Jira Software projects.”
Factom has three different engineering teams (20-30 engineers), focused respectively on front end, enterprise, and open source services, each working out of a unique Jira Software project. As a result, being able to visualize and understand the impact across projects has proven invaluable for the Factom team.
Labels within Portfolio for Jira have also been a resource for helping with prioritization. Carl points out the sometimes an epic may fit within multiple “programs.” So if one program gets prioritized first, he’ll use labels to identify certain epics that may need to be reassigned to the program with the highest priority.
Finally, in order to communicate his plan with stakeholders, Carl embeds Portfolio’s schedule report into a Confluence page and shares it. The benefit of embedding a Portfolio plan into Confluence is that it stays up-to-date as things change so stakeholders always get the “live” version of the plan.
The nuts and bolts that go into Factom’s Portfolio for Jira plan
At the foundation of Carl’s Portfolio for Jira plan, he uses one Jira Software scrum board and one filter as issue sources. Using the scrum board as an issue source, he’s able to pull into Portfolio all issues from the team’s board as well as the team’s velocity. Carl also uses a JQL filter as an issue source so he can pull in issues that may be blockers from a separate project. Bringing dependencies from another project into his Portfolio plan is helpful for building an accurate plan.
The Factom team uses releases in Portfolio to represent significant customer-facing milestones and to forecast a launch date (they do this by setting their release date to “dynamic” within the tool). They also take advantage of Portfolio’s cross-project releases, where they roll issues from multiple Jira Software projects into a single release. Forecasting significant customer milestones across multiple Jira Software projects has been helpful for keeping cross-functional teams aligned, from the teams that are building the products to teams that need to communicate launches to customers.
Tips for getting started
Carl recommends starting simple with Portfolio. Specifically, he suggests not inputting individual team members into the tool at the outset because it requires a lot of administrative overhead, which can become time-consuming. Instead, he suggests focusing on getting a stable velocity associated with each team, which is important for building a meaningful roadmap in Portfolio.
Using Portfolio for Jira, the Factom team was able to ensure the roadmap is always in-sync with the engineering work being managed in Jira Software. Accordingly, they’ve been able to save a lot of time that they would’ve otherwise spent on administrative activities like updating spreadsheets and communicating status. They’ve also been able to paint a more realistic picture of what they can deliver in a quarter.