Every year we define our main goals and agree on a roadmap for the coming year. Of course, nothing is ever written in stone and the yearly plan often goes through many iterations. Customer requests, business constraints, marketing events, engineer’s creativity - are all good reasons for modifying it. As our roadmap plays a crucial role in keeping us on track with our rapid pace of development and helps us meet and exceed our customers’ expectations, I will tell you all about how we do it!
The Key to Agility: LTS Version Every Year, FTS Release Every 2 Months
Nuxeo releases a Long Term Support (LTS) version of the Nuxeo Platform every year and a Fast Track (FT) version every 2 months. We build our way up to the LTS releases with the Fast Track milestones. This has several advantages:
- It’s a great way to secure the achievement of the year! Each Fast Track has its own set of focus points or objectives. The trick is to make sure that the focus points in the early Fast Tracks are the right ones if we want to make it to the LTS smoothly. Also, it is easier to manage four or five small objectives than a big one.
- By defining what is expected in a given Fast Track, developers better know what their priority is for the next two months. Each item on the roadmap is assigned to one of the teams and has a related ‘Epic’ which ultimately boils down to user stories and tasks.
- The two-month release cycle of Fast Tracks also allows greater agility for reprioritizing features - any reasonable feature request is included in the next release of Nuxeo, which means the feature will never be more than 4 months away! This allows us to take our customers’ requests into account at the earliest.
The Nuxeo Roadmap: JIRA + A Custom AngularJS App
A simple filter in JIRA, let’s say on Epics, was not convenient enough for the requirements of sharing the Nuxeo roadmap. The roadmap:
- Must reflect the LTS/Fast Track organization we have.
- Must be attractive - it is part of the vitrine of the company, along with the website.
- Must be always up-to-date.
- Must have access to any mockups, screenshots, videos of the objectives, as well as any user, developer or admin documentation, since the roadmap is the foundation of Product Marketing in Nuxeo. Also, since we are an open source company a link to the sources should be there too.
- Must be tightly integrated with JIRA which is ideal for the Nuxeo Platform Projects.
In the end, it’s a tool used by the Product and Engineering teams for scheduling and prioritization, by the Sales team and customers for tracking some specific features or getting useful information around new ones, and by the Marketing team for preparing the communication around each releases.
To achieve these goals, we have come up with a custom AngularJS application that displays custom roadmap items of a dedicated JIRA project. The roadmap item ticket type holds all the necessary information (useful links, confidence score, status etc). The AngularJS website displays them in a nice way, browsable and filterable by version and components. A view for a given item as been implemented to send a link to a customer. A confidence score gives us an idea of whether an item in the roadmap will make it into the release it is supposed to be in. The confidence score has 3 levels: glassy, moderate, and rough. All useful links are displayed on each item and screenshots are browsable via a lightbox system.
Screenshot of the Nuxeo Roadmap
The AngularJS application is available on GitHub and relies on the Atlassian JIRA REST API. Feel free to fork or send pull requests! It is definitively a great application for displaying roadmaps using JIRA.
What Needs to be Improved
The Fast Track cycle is great but there are some impediments which we are improving on:
Reducing the footprint of a release
- The release comes with feature freeze (no more features can be merged into the master branch) and code freeze (no code commits at all except for fixing a blocking bug). This means that the development flow is somewhat disturbed, even though it is always possible to develop in branches and there should be no disturbance. Still, the shorter those freezing periods are, the better it is! The most efficient way to solve this is to have more and more tests with quicker feedback for the developers, as well as branch-based testing environment automated provisioning.
- The release comes with release notes, documentation, etc. Once again, releasing every two months shows you how better it is if all those tasks are correctly handled on the go, by the dev team in charge of a feature. This is where we are heading, but for now we see a lot happening in the last two weeks of the two months period!
Slipping roadmap items and release cycle unsynchronization Some items tend to slip from one Fast Track to another. It is better to have the whole team finishing a roadmap item or two before starting a third one. It would be nice to start with new topics immediately after a Fast Track release, but this is way too idealistic! The best way is for a given team to have a clear view of the roadmap item priorities so that they can own the topic in advance and start planning it.
Technical constraints versus scheduling Each year is the same - you have to think early enough about low-level technical evolutions so that you can benefit from them and leverage them in the the LTS cycle for new features and UI. But sometimes innovation at the low level comes with surprises, and it is hard to have an accurate forecast of when we can possibly leverage them. But again, wouldn’t it be boring otherwise? ?