Your Agile Project Needs a Roadmap

As teams begin to adopt agile in their organizations, one of the most typical (and costly) errors I see is the lack of an overall vision of the project. Now, I’m not talking about that vision of what a product might do, its benefits to customers or the markets it might create. This part is actually done pretty well (in my experience). Business people, product owners, etc are more than eager to tell us why their projects are critical and stand out. And many times these discussions go all the way through the teams. Nope, that’s not what I’m referring to…

The issue I see is a lack of clarity in large projects related to a Roadmap.
The following diagrams show a few different pictures of a basic Agile Project Roadmap. In my view, when we commit to large scale project with critical deadlines, we need to show a thumbnail sketch of our intentions. We need to see the universe of currently known Features, User Stories, Epics, etc and where they might land between today and project end. Not only that, we as a project team need to work hard to define critical stories (business and technical) and shuttle them toward the front of the project in the form of a “walking skeleton”. We do this so we can raise the probability of achieving a delivery that gives our customers value (Alas the complete point :))

The Roadmap is not a guarantee. Nor does a Roadmap commit to delivering Features. It commits to a DATE and VALUE. (Yes I said DATE) If you haven’t learned that we all live by deadlines, stop reading now. The rest of this won’t help you.

I’ve Traveled Thousands of Miles and Could Only See as Far as my Headlights

It also helps the team refer back to the something that describes the overall project and our destination. Think of it this way…If you leave on a long car trip, we start by referencing a MAP and beginning our journey. There are times where things seem clear and the daytime illuminates the road and the road signs as we make our way. As the miles pass (and hours) and day turns to night, we can still progress toward the goal. We can only see as far as the headlights, but we can travel for hours this way. However, we still need to reference the MAP. We might have strayed from the original vision (by circumstance or a personal decision) but we still need to find our bearings and proceed. This is indeed what an agile Roadmap will do. It gives us the destination and a thumbnail sketch that we can reference when things get “fuzzy”. It won’t tell us the detail, just gives us an idea and needed confidence.

Roadmap – Initial Outlook

Below are the examples. The first shows a basic Roadmap after a Blitz Planning Session where we’ve identified architecturally significant and business critical Stories and Features. You can see in the beginning, we elicit just enough requirements to get going and work ahead of the team (“Iteration Ready Stories”). You can also see that we pushed all starred “walking skeleton” stories to the front of the project to help us raise the probability of learning early, and delivering the MOST critical pieces (recall VALUE as a primary objective). We can then slot the stories, features, and epics into the Roadmap based on basic Relative Estimation techniques (ie User Story 47 looks exactly like User Story 3).

Roadmap – In Flight Project

Now, let’s imagine we’ve just finished Iteration 3. The next image shows what the Roadmap might look like. You can see that we’ve delivered most of the walking skeleton and we’re approaching that threshold where everything critical is delivered. This is HUGE! You can also see that, during the project, we undoubtedly had to ADD stories as we learned more (visualized in Green). Conversely, we’ve also had to REMOVE some stories that didn’t make sense any longer (Red X’s). We are still eliciting requirements just in front of the development team (visualized as Pink “Iteration Ready Stories”). Notice we have NOT moved the date. However, we HAVE added enough stories to push the entire universe of stories PAST the end date. How could this be? Well, these features represent our ability to say YES to any features that hits the team as long as the team and the Product Owner can see that new features might represent ADDITIONAL FUNDING. This is indeed what a Roadmap will help us discover. But no matter. If funding is frozen, we have delivered the critical pieces by Iteration 4. The remaining iterations are Gravy. (…mmmmm, gravy)

Please let me know your thoughts!

7 thoughts on “Your Agile Project Needs a Roadmap

  1. Pingback: Jason Montague
  2. Pingback: SQA World
  3. Pingback: SQAConnect
  4. Pingback: Jason Montague
  5. Pingback: César Idrovo
  6. Pingback: lisaw1
  7. Pingback: Adam Monago

Leave a Reply

Your email address will not be published.