Roadmap Plannings for Epics — Figuring Out What’s Next

It becomes harder and harder to keep people on the same page as engineering organizations shift from startup to growth phase. As a result, some of these phrases can begin to percolate.

• Hey so once we’re done with [insert epic] what are we working on next?
• I can’t tell what’s going on in their sprint — the tickets don’t make sense
• Wait, they’ve been working on what for two months??

We definitely want to prevent the last one.

At times, getting everyone on the same page even within one team can be challenging. But what we’re talking about is cross-discipline horizontally with Dev, Quality Engineering, Security, and Operations, but also vertically from the team level to senior leadership, while aiming to keep the organization and teams Agile.

It can end up feeling like herding cats.

We use Roadmap Planning meetings at FloQast to help us get through these challenges and have found they start with one of the most basic units of Agile methodology: The user story.

Using the Familiar

At FloQast, our user story process is similar to many engineering organizations:

• Write a story that describes user value
• Groom the story with the team to refine and clarify the problem set from all sides
• Estimate as a team
• Prioritize when the work gets done
• Get it out to users

Under the hood, the above focuses on the user and gets people of various disciplines to be in alignment on how to approach solving the problem.

Stepping One Level Higher

We take this same process for grooming user stories into a Roadmap Planning Meeting for epics, usually on a monthly basis. These meetings include a mix of team-level and senior leadership from the Engineering and Product groups. The focus of this meeting boils down to prioritization of our Now, Next, and Later.

Epics

Just like with sprint planning, Roadmap Planning works by discussing which epics that a team is focused on. We’ve defined an epic as a clear, focused user-story style problem that gives value to FloQast. The epic answers product criteria and business value.

Time and Granularity

Moving Between Columns

Each column is a representation of time and granularity as the work gets closer to the team working on it.

Later

Timeframe: ~4 months to ∞

Who: Product management gathers data to present the what and the why for the epic to be moved into the Next column to stakeholders at the Roadmap Meeting. Based on the aforementioned product criteria and business value, stakeholders agree on one of two actions:

• Prioritize the epic within the Later column for further data and/or reduction of scope
• Select an epic to move into the Next column (Figure A)

For technical epics (Reduce response times across x service), team-level engineering leadership (Tech Lead/Engineering Manager) gathers data to present the what and the why and high-level how in the form of an Engineering Requirements Document. It then follows the same process as above.

Next

Timeframe: ~1 month to ~3 months

Who: Team-level engineering leadership (Tech Lead/Engineering Manager) begin to form the how through an Engineering Requirements Document, which will include a base explanation of how to solve the problem described and may also include such artifacts as architectural diagrams which would be vetted by Ops, Security, and QE teams. The what, why, and high-level how are also discussed with the teams themselves, to come up with a rough t-shirt estimate. This process is done for a max of 2 epics at any given time, and the artifacts of this are then shared at the next Roadmap Meeting with stakeholders. (Dotted line boxes in diagram)

In the Roadmap Meeting, two actions can occur:

• If the artifacts align with stakeholder goals, then the epic stays in the Next column, to eventually be broken out into granular stories by the entire team, and then becomes the Now (Figure B)
• If after the ERD the stakeholders decide to hold off, the epic is moved back to Later. (Figure A)

Now

Timeframe: Now to ~1 month

Who: The entire team, including Tech Lead, Product Manager, and Engineering Manager are in some way responsible for shepherding through to delivery. Highest granularity of detail, with the epic broken out into stories spread out over sprints. The team knows the how, what, and why for each story.

Estimating Effort

Epics are based on effort and complexity. It intentionally does not have a time component, as this can become inaccurate with varying team sizes and velocities which would provide the wrong data points to stakeholders as they are looking to make a decision.

Setting a Baseline

Sometimes, organizations run into the question of, “What’s a large” and the way FloQast solves this is by picking a previous epic we’ve done in the past and using that as our baseline. So for example, one team may have worked on Epic X and we’ll set that as a Medium. Then, the question becomes, “If Epic X is a medium, would you put Epic Y as a small, medium, or large compared to that epic.” This does generically give a sense of timing that stakeholders are looking for, but doesn’t presume a specific date for release.

Epics tend to fall in the range of Small, Medium, and Large. There may be an estimate that is an Extra Small (XS) – which is most likely a story and not an epic. In addition, if an estimate is Extra Large (XL) it usually means the scope needs to be reduced for better estimation.

Agenda for a Roadmap Meeting

So what does the agenda of a roadmap meeting look like? This may vary from team to team, but an example is:

• Current work in progress, and general dates the team is trending to completion
• Upcoming epic to vet

The first part is more or less the status update, while the second is the larger question of what is the next most important thing that gives the user the most value.

Fan-Out

Once the Roadmap Meeting is complete, teams are informed of decisions that were made and impacts to their roadmap. This can be as simple as sharing the presentation or discussing at the next grooming/planning meeting.

Wrapping Up

As FloQast continues to grow, we continually look to solve problems in a collaborative way with our teams in a way that sets them up for success. While these team-level Roadmap meetings don’t encompass the entirety of our strategic conversations, they are a valuable part of how we make decisions that percolate to our teams.

Vinoj Zacharia

Vinoj Zacharia is a developer turned engineering leader who leads with empathy to build data-driven, empowered, collaborative teams from the ground-up. He is a Director of Engineering at FloQast.