Product Roadmaps - When Good Enough Just Isn't Good Enough

[#1]

In this article we will discuss how microservices and micro-frontends architecture empowers teams to deliver more frequently and independently to production. And when established product-centric roadmaps aren't good enough to answer the question “When will it be delivered?“ We will also outline why delivery-centric roadmaps are a better fit and what are the ways to define your release scope in Jira in order to plan, orchestrate and deliver a release cross-team, cross-project or cross-company.

The world has changed

The world of ‘software development’ has changed. Most backends nowadays are based on services and microservices (m/s). They are also owned and delivered by different teams independently. Some of them are single-tenant serving specific clients or segments. Others are multi-tenant serving all the clients in a specific region or Datacenter (DC). Micro Frontends is also picking up to do the same for client-facing Apps what m/s did for backend.

With all this new eco-system in place almost any feature you develop presumes changes in multiple m/s, widgets that need to be delivered to finally toggle ON your feature flag. To make things easier you can always package those changes somehow in a single delivery or orchestrate multiple deliveries in a coordinated fashion.

But you ‘do not want to’, mainly because:

• technology is built for - and empowers - independent, incremental and iterative delivery
• you don't deliver one feature at a time; you deliver dozens on a regular basis
• “time to market matters” and you want to deliver something as soon as you have it working and just turn it on when all the dependencies are ready and in place.

Product-centric roadmaps don't answer

Product-centric roadmaps are usually built around the structure of software requirements (e.g. Initiatives split into Epics that are split into Stories and/or Technical Tasks). Stories and Tasks are usually Team level and sit with teams and their deliveries. But Epics in most cases span across different teams/departments (some call it Program level), and the notion of delivery and ownership is becoming blurred.

It’s very difficult to answer the question when a small Feature  will be delivered, because usually it includes changes in multiple services and frontends owned and delivered by different teams with their own delivery technique and cadence.

Things get worse if this feature requires configuration per client (b2b) or customer segment (b2c)... or you have a distributed production environment with a private cloud in the US and another one in EMEA. This is when questions like “When will Feature X be delivered?” become really tough to answer.

Delivery-centric roadmaps can help

One of ‘The Key Values and Principles of Agile Manifesto’ says

Working software is the primary measure of progress.

What is working software? Software deployed to the production environment and configured for the end customers to use. There’s no credit given to anything partial.

If you look at it from this perspective, your ‘working’ Feature X is becoming a set of deployments of a set of services and Apps with appropriate configurations applied. We will be calling these deployments ‘releases’, comprised of the changes engineering teams performed to implement the requirements given for Feature X.

Helping how?

Planning, visualizing, orchestrating and deploying your releases across multiple services and Apps will give you the ultimate solution to answer the question “When will it be delivered?“. But also help in a way to manage the flow of different deliveries happening, spot impediments, clearly understand the impact, and manage the expectations on a) “Why so slow?” and b) “What’s the new date?“

Release Management beyond ‘Affects version and Fix version’ in Jira

In Atlassian Jira, release management is all about ‘Affects versions and Fix versions’ standard fields that are tied to any issue type you create. They are referencing a unified lookup that is configured on Project level and can't be shared cross-project.

So, in order for you to define your release scope, you need to add a new version in Releases lookup and assign issues to it via the Fix Version field.

This might be good enough if you track your different components in separate projects and have a good culture of using the Fix Version field. It would also be okay to have a plain list of versions of different Apps and services if you track it all in a single project (just difficult sometimes not to get lost in this list).

Once you track releases of individual components as Fix Versions you need a tool to aggregate them into something bigger to track your Epics/Features or more complex releases’ cross components/projects. There are a number of Apps on Atlassian Marketplace to help with that.

Sometimes it is useful to ‘simulate’ a single version across projects (not supported by Jira out of the box). Again, most of these tools from the Marketplace have a versions-sync functionality cross-project.

Jira Epic as deliverable?

Some companies do not use fix versions and use Jira Epics instead to define scope of releases. And for a good reason:- in the former Classic and now Company-managed projects (CMP) you can share your Epic across projects to aggregate work from different services and Apps to deliver Features. If you link here tasks from DevOps and Change Management (CM) projects (if tracked separately). Epics could easily become deliverables. For better tracking you can use Due Date or any other custom date field as Release Date and build all the reporting accordingly.

In former NextGen and new Team-managed projects (TPM) Epics are tied to the project and you get a deja vu with Fix Versions. They may be still good enough to treat these individual Epics as deliverables but most probably you would need similar tooling to aggregate them into something bigger to orchestrate end-to-end delivery and/or sync those Epics across all projects to ‘simulate’ single delivery (from a business perspective).

Sprints in Jira as deliverable?

Some of the Scrum adepts would be puzzling reading up to here:- “What are they talking about? We deliver at the end of each sprint (!)“. If this is true we really admire it. Same time Sprint in most cases is a team level delivery, and if you want to release something across teams you need to find ways to aggregate and orchestrate sprints as deliverables. So, the problem statement seems similar to Fix Versions for individual projects or Epics from different TPMs. Probably with a difference of ‘talking and talking’ Sprints from different boards to aggregate in single end-to-end deliveries and orchestrate accordingly.

Custom JQL as deliverable?

What is ‘Release’ in Jira?:- it’s all the issues where the fixVersion field equals the Release name.

What is ‘Epic’?: - all the issues with Epic link equals to Epic key.

What is ‘Sprint’? - all the issues with Sprint being in the Sprint name.

So, it’s just a JQL (!)

Why can’t we define even more Custom JQL then as deliverable? We can. Just define how you want to differentiate deliverables and what attributes and values are to be used (Jira labels seem an obvious choice but not limited to) for tracking your release.

Probably a good tool that will allow you to package such custom JQL and bring Release notion to it with necessary attributes will be very beneficial.

Mixing all the above

The above options give you flexibility as there is no one size fits all. The reality is you most probably would need to combine them, as organizations are varied, and internally might use different approaches towards release management.

E.g. Imagine a bank with some legacy backend solutions being delivered on a fixed cadence, and let’s say Fix Versions are used. Same time you have a new innovative department (or a third-party) responsible for online or mobile banking with established CI/CD practices and deliverables by Epics or Sprints. Now you want to develop and deliver a feature that goes across those 2 departments and orchestrates such deliverables.

Ideally to have options to aggregate Fix Versions from one project and Epics or Sprints as deliverables from others to orchestrate and delivery cross-project release. There are Apps on Atlassian Marketplace to help you with that.

A few take away notes

The new world of software development presumes microservices and micro-frontends architecture empowers multiple teams to continuously deliver to production completely independently from each other. Disregard the fact that Product-centric roadmaps are good for planning work, they can’t help with questions like “When will it be delivered?“ Delivery-centric roadmaps can, and there are tools to plan, orchestrate, and deliver release giving you ultimate flexibility to define the scope of your deliveries in Jira

• either via Fix Version field and Releases in Jira
• or Epics
• or Sprints
• or Custom JQL

as well as a mix of those approaches to make cross-Jira projects ensuring end-to-end delivery.

Who ‘we’ are?

We are one of the partners on Atlassian Marketplace who focus on Release Management and Delivery-centric Roadmaps solutions for Jira, both Cloud and Datacenter. Our mantra is “Working software is the primary measure of progress“ and we truly believe in the statements we wrote in this article. We would be happy to have a constructive discussion in comments to this article or you can always reach out to us via our Service Desk.

Stay tuned! 

[Ulrich Kuhnhardt _IzymesCo_]

Great insights! Delivery by JQL sounds promising. 

[Jimi Wikman]

Good article Yuri and it illustrates some misconceptions that I often see in organizations regarding roadmaps, especially surrounding releases and what Jira actually do, but also the expectations of deliverables related to strategic planning.

So let us start with releases, where there is no release management in Jira. At all. Fix version and Affects version has nothing to do with releases, or deploy as they are simply connecting code with version numbers, or tags, in your code. In short, that means you are referring to code packages.

When you deploy code you select one, or more, packages and the deployment of code can be tracked in Jira with the integrations, but it has nothing to do with Fix Version or Affects version. These are just manual markings that help you understand in what package certain tasks are located.

When you make shared releases across multiple systems, this is also something that Jira can not track because each system has its own versioning based on that system's code. It is also pointless to track releases or deploys in such scenarios, as strategic roadmaps do not track code, they track value.

As you have already concluded, this is what Epics are used for in many cases, and sometimes there is a level above that as well. So these are what you should track on a strategic level so you know when value is released to the end users. This also ensures that no matter what your cadence is for deploys, or how you slice your tasks, you know when value is available in production, which is what we are interested of in the strategic roadmap.

So Release is used internally by the system teams to track branches or code packages. Epic/Feature is used to track value across the organization, and sprints are just checkpoints of time that we use to align progress often and to ensure we can manage change as we work.

[Yuri Kudin]

Hi @Jimi Wikman ,

Thank you for your comprehansive comment on the topic. What you are mentioning is correct and it could perfectly work for some organizations, especially with small and medium sizes.
But let's imagine that you need to deliver a business feature that will impact 10-20 components and it should be delivered to multiple environments or data centres.

Each component could be developed by a separate team with a slightly different SDLC and development cadence (yes, there is no alignment in enterprise in real life and it might not be needed at all).
In that case, it would be nice to pre-plan and track the deliverables of all components, and make sure that all of them are updated in a certain environment before enabling the feature.

One of the ways to do so is using FixVersion even if it will not fully match an exact artefact that will be deployed. Also, we might have multiple deployments of multiple artefacts during the version development, we can just see it in the Release management app and map fix version to multiple deployments. The main point that we need to know is that a certain artefact is available in a certain environment and ready for interaction and enabling the feature by a feature flag.

Also, there are technical dependencies that have to be tracked while development (for instance, one team is making a mock API to allow the other team to do early integration and make integration tests and after that, the mock API will be replaced with a real one). Using issue links is not really convenient as it will create a lot of complexity. We need to move to the program level (if we follow SAFe terminology) to track them.
Another thing: when we complete all stories in the epics, does it mean that we can automatically go live and just deploy some components to production under the hoods? At least we need to make sure that:
All components of our 10-20 components with all proper versions are deployed in required environments

• Run integration tests
• We tested NFRs. For instance load testing (unfortunately, not all companies can do it in fully automated mode, especially with legacy systems)
• Also, we might need to obtain approval of the Change Advisory Board or Compliance or Regulator, if we are operating in a regulated market.

Based on experience, it could happen when the versions of components might wait for a long time till all approvals will be obtained even if all user stories and epics are closed a long time ago.
Or, another case: we can develop something for a month but roll it out for two months if we have plenty of clients with separated data centres on-premises.

I am leading to the point that enterprises don't have the luxury just to deploy on cadence or on demand. Plus some level of coordination from the technical side, on component and technical level, will be done alongside with classic roadmap when we track epics and stories.

Both roadmaps and tools are useful for different audiences.

• Business people will benefit from having Initiative -> Epic -> Story view and track value delivery as you have mentioned in your message. They will not care about versions, artefacts, environments, deployments and all other boring technical stuff
• Engineering people are very interested in how they will implement, and what is most important, integrate all the code (that is developed by multiple teams btw), test on all levels, obtain all approvals, coordinate with SRE and deploy to propper environments and ensure NFRs.

So we can use a spoon for the soup and a fork for the potato :) 

[Jimi Wikman]

Good points Yuri, but I think you are mixing plans with code and you are tying it to a task management system that has no capabilities to measure or track value that we need in your scenario.

What you are referring to is a program level event with multiple projects that have multiple development tracks. Very common and not very difficult to track using either Advanced Roadmaps with custom levels or add-ons like BigPicture.

The first thing that is done is to set the value deliveries in the program, because that is what we are interested in on a strategic level.  Then we break that down into where the value need to be created, meaning what systems do we need to develop new code in.  From there, we define logical chunks of work and assign them as projects.

Each project is broken down into features, and every feature into tasks. Just like every project is.

We then connect all of this with dependencies and set an overall plan for execution at the program level. This is where we make the timeline and adjust development for toggle features och temporary solutions like a mock API or a temporary message broker before we replace things. We check to see if we need multiple solutions if we for example replace a system so we need both the legacy setup and the new setup during the transition period.

The dependencies determine when code need to be released based on when in time they must be ready not to affect the overall timeline and we track completion of features and projects to determine program level progress.

The teams should know all dependencies and they should work together according to the project and program plans. They will work with version numbers internally to track their code and they will communicate status of dependencies to the other teams as normal.

From a release or rollout perspective, you don't care about individual tasks, you only care about feature readiness and blockers that might occur that cause timelines to break the project and program plan.

From a test perspective, you do the exact same thing, but from a system perspective rather than a program perspective. You have a program level test plan for things like E2E testing, load testing and pentesting and then you have system specific test plans for feature testing and integration testing that matches the development time plan on program and project level.

This ensures development is completed and test can be done properly in time for the next part of your dependency map in your program so you don't get stuck. Obviously, you want extra time to test if you find defects, so your time plan does not get screwed up because you forgot to add time to correct.

This is just a higher level of normal project management and team collaboration and it should have little to no implications on the daily work in the teams as you add people to the Program and projects to handle the coordination of dependencies.

FixVersion and AffectsVersion is just for the teams and outside the team we track progress based on feature completion which are either Epics or higher issue types presented in either Advanced Roadmaps, an add-on or just excel if you hate yourself and want to do it manually :)

[Yuri Kudin]

As usual, thank you, @Jimi Wikman for the comment.

I completely agreed that Advanced Roadmaps could be used for planning and tracking value delivered (or any other add-on like that. Personally, I prefer Structure+ Structure Gantt for this purpose). All is clear and logical with splitting the work: Initiatives, Features, Epics, Stories etc. This would be a good choice for business and product people who are interested in value delivered and don't want to think about some technical stuff but engineering people would need to think about how to deliver this value to the production, fulfil all requirements for NFRs, plan technical dependencies and fulfilling other requirements before going live. Of course, you might say that all the tasks could be created and added to initiatives, features, epics etc but, they will produce certain overhead for business people that might do not want to see extra tasks under epic, that might not be really "human readable" for them :)

You have mentioned that " The teams should know all dependencies and they should work together according to the project and program plans. They will work with version numbers internally to track their code and they will communicate the status of dependencies to the other teams as normal."

So Release management is the tool to help them to know all dependencies, work better with other teams and keep the focus on technical integration points and track internal versions in a way that will tell what is deployed and where. In addition, make sure to go to production process unification. As result, no excel is needed (btw, teams who don't use Release management track environments in excel ;) )

To conclude, business and product people have certain needs and ways of working that you have explained very well in your comment. But, we have engineering people in the company, who have different needs than business people, especially at scale. In the article, I am advocating engineering needs and sharing the idea that they should be organised in parallel with business needs. They should visualize the same reality but from a different angle.

[Jimi Wikman]

"So Release management is the tool to help them to know all dependencies, work better with other teams and keep the focus on technical integration points..."

No, this is not what release management is. Release management is the coordination and planning of releases. It has nothing to do with planning the work that proceeds the releases.

If you have people that want to go into the details of the releases, then of course they can do that. Jira and Confluence both provide the possibility to track upwards and downwards in the documentation stack and the task management stack.

Do you want to know when a feature has been fully released? Then look at the feature level. Do you want to know when a part of the feature has been released to a certain system, look at the system level. Do you want to see when projects have been released? Look at the project level.

FixVersion and Affects version only exist in Jira and as we have already established, Jira is not a release management tool. So you can drill into a system release if you want, or if you have a project or even business version in Jira, then you can drill down on those if you want. You will never be able to see context however because a Jira project release have no relations to other releases.

So you can not use those for any form of release planning because they are one dimensional.