February 23, 2016

Scaling Agile, Step 3: The Roadmap Document

Helix ALM
Agile
step3In previous blog posts, I’ve talked about the first two of the six steps for successfully scaling Agile. Step 1 is the Kanban feature flow, and Step 2 is traditional portfolio scoring. This time, I’m going to look at Step 3—the roadmap document—and talk about how TestTrack can simplify creating and managing this valuable planning tool. Before I begin, let’s define what I mean by “roadmap document.” A product roadmap is a high-level planning document that lays out a schedule for changes and additions to a product. It often covers several future versions or releases of the product, providing a way to prepare for work that’s “down the road.”

Why Are Roadmaps So Valuable?

The roadmap document provides visibility to different teams involved in developing the product, keeping everyone on the same page. It guides the medium- and long-term development of your product, showing how everything fits into the big picture, providing context, and setting expectations. Roadmaps can also help you focus on high-priority work. Without a roadmap, it’s easy to put off more difficult tasks so you can quickly finish a bunch of easy features and updates. Building a roadmap gives you a framework to help you stay on track. Another nice thing about roadmaps? They can keep people from pestering you about when you’re going to get around to their pet feature. And if it doesn’t stop them from pestering you, you can just tell them to check the roadmap.

Creating and Maintaining Your Roadmap Document

You can use tools like Microsoft Word, Excel, or PowerPoint to create and maintain your roadmap, but it creates a break in your process that requires you to manually copy information about features to and from the document. Not only can this be difficult and time-consuming, but it also increases the possibility for errors. Using these tools also limits your ability to control who has access to the roadmap, and who can make changes to it. This can result in scope creep, and in some cases, the final feature may not end up resembling the original feature request very much. And then there’s the problem of communication. If you email the roadmap document to everyone on the team, that means they all have a static copy of it. How will you keep them updated when the roadmap changes? If you email everyone an updated copy, you’re adding more work to the pile and increasing the possibility that errors will creep in. To scale Agile effectively, the roadmap needs to be a full-fledged member of your end-to-end process. Using a collaborative tool like TestTrack can incorporate your roadmap seamlessly into your process, and also eliminate the need to manually create and maintain a separate document.

Creating Roadmap Documents in TestTrack

With TestTrack, features from your portfolio can easily be added to the roadmap document. Because the features are already in your product portfolio, you can simply drag them into the appropriate part of your roadmap document. No static documents, spreadsheets, or slides needed. Once your roadmap is created in TestTrack, everyone on the team can view it. When changes are made, everyone on the team can be notified automatically, too. No more need to email updated copies or worry about the team getting out of sync. Not everyone can make changes, however. TestTrack also gives you the ability to lock your roadmap document using workflow features. Once locked, team members without the right authorizations can perform some actions, but not others. The table below gives you an overview of what is and isn’t allowed for these users. [caption id="attachment_18216" align="aligncenter" width="625"]When your roadmap document is locked, users without the proper authorization are limited to certain actions. When your roadmap document is locked, users without the proper authorization are limited to certain actions.[/caption]

Snapshots and History

Another advantage of TestTrack is the ability to curate the changes to your roadmap documents using snapshots and the History tab, which allow you to see the changes in scope over time. A snapshot is a version of the roadmap document captured at a specific moment. Snapshots are used for comparing document versions and viewing differences between them, so you can capture an agreed scope at a certain point in time. If you need to refer to the original document version later, you can view the differences between the snapshot and a newer version to see what changed. You can view snapshot details to see the snapshot number and label, who created a snapshot, when it was created, and comments entered when the snapshot was created. You can also set TestTrack to automatically create snapshots at certain trigger events—each time the roadmap document is saved, for example. Even if you don’t take a snapshot, every change made in TestTrack is fully recorded as part of the history. You can view historical information for each item in the roadmap document, including the user who made the change, when it was changed, and all the details of the change. All of this information is available by selecting the item and then clicking the History tab. No more arguing about whose idea the changes were! [caption id="attachment_18218" align="aligncenter" width="900"]An example of the roadmap document as it looks in TestTrack. An example of the roadmap document as it looks in TestTrack.[/caption]

Managing Changes to the Roadmap

Deciding to make changes to the roadmap is almost always a collaborative process. Many people require a change board to authorize all the work items that go into their roadmap in the first place, as well as any subsequent changes. I think using a document is a pretty natural and easy way of recording these changes. The good thing about managing the roadmap document in TestTrack? You can record not only the final text you have agreed on and have a complete history of all the changes made to the text, but you can also add comments about why each change to the text was made. This helps everyone stay on the same page. The ability to manage change is one of the main reasons for wanting your roadmap document to be a fully integrated part of your process. Because items in your roadmap are linked to downstream artifacts (user stories, tasks, and so on), it’s infinitely easier to manage impact assessment and notify downstream parties of any changes with automated emails, suspect flagging, and TestTrack’s set of traceability management tools. Without these features, it is tremendously difficult to make necessary changes to your roadmap with confidence that downstream teams will effectively implement them.

Getting to Work

With the completion of the roadmap document, the strategic planning part of your project is done and you’re ready to move into the last three steps in scaling Agile. These steps are where the work begins—breaking down features into user stories, ranking those user stories in your backlog, and beginning on your sprints and tasks. I think the work in those steps is familiar enough that I don’t need to break it down, but I do talk about it in the webinar recording, so give that a look if you want more information. TestTrack glues all of these steps together for a unified development process that allows teams to be Agile—even at the enterprise level. If you think you’re “too big for Agile,” check out TestTrack and let’s have a chat. I’d love to prove you wrong.