Building Community Roadmaps

A project roadmap is a valuable document for a community open source project. For growing projects, even when the developers are predominantly working for one company, the roadmap is invaluable and accomplishes a number of things at once:

• It is a great tool for setting shared priorities and setting limits for what is in and out of scope for the project
• It encourages the developer team to be transparent about planning and provides context for more discrete quantities of work
• For engaged community members, it gives an opportunity to contribute to the improvement of the project, by suggesting features which are not on the roadmap, or by volunteering to develop features, which are included but not yet committed by the core team
• Finally, for casual users of the project, and visitors evaluating whether they would like to use the project, it gives an idea of what is coming down the road

Putting together and maintaining a roadmap over time can be a challenge. There are two main dimensions involved: the number of things to include on the roadmap, and the amount of time covered by the roadmap.

There is a temptation, when drafting a roadmap for the first time, to put everything and the kitchen sink in it. You should resist that temptation. I think it is better to choose a small number (four or five) of high priority big goals, and to figure out what is involved in delivering those.

For time, it is not possible to plan three or four years out for most projects. A reasonable planning time frame might be 6 to 18 months, depending on the type of project, size of team, etc. I like a kind of fractal planning method: for a release in 12 or more months, you might have a theme in mind (“Launch plug-in portal”), without a clear idea of what is involved. As you get closer to the release, you start to flesh out what is involved, and break down the big goal into more digestible chunks (something a person might get done in a single release or sprint). Finally, when planning features in detail, they can be broken down into checklists of work items that need to be done. For the current release or sprint, you should have a very good idea what will be done, down to the individual work item (bug, checklist item).

By starting with broad themes for releases planned out some time in advance, you ensure that releases tend to have some major user-facing functionality that you can promote. Without a theme, “business as usual” tends to take over, and the community can lack direction.

By keeping to a small number of themes and breaking them down progressively over time, you also avoid the problem of the roadmap deviating from reality, and becoming useless as a planning tool.

It’s important that the roadmap is maintained. The maintenance can be by a designated community member, a release manager, a product manager, or a group effort. The important thing is, on a regular cadence (every sprint or release), the roadmap is revisited, to see whether future themes are still important, to plan for the next sprints, and to break down bigger themes that are getting closer into a more concrete list of tasks.

Finally, it’s important to indicate, particularly if this is a project with a lot of full time developers, what your development team has committed to, and which tasks you would *like* to have, but are not resourced or planned. In this way, you leave seats at the table, and establish an expectation that if someone from outside of your team implements a feature that it is likely to be accepted.

Good community roadmaps combine all of these characteristics, providing direction for the future, fulfilling a need for planning and tracking execution, and providing an ability for community members to engage in the development process by seeing what is coming, and providing opportunities to get involved.

Image courtesy of ErikaWittlieb under CC0 1.0 Creative Commons.