The Value of a Sprint Roadmap in an Agile Development Process

One of the biggest challenges of managing a project using Agile development practices is managing up to the business folks about project completion dates.  Particularly in organizations where Agile is a new thing they are trying, and they are accustomed to doing waterfall style development planning where all development efforts are sized up at the beginning of the project and laid out end to end in a dependency chart.  The challenge with Agile is there are a lots of great ways to show team velocity and current status of what you have done, but being able to show when you are going to get the rest of everything else the business wants done is more difficult, because estimating and sizing the whole project goes against the grain of how Agile methodology is supposed to work.

For these reasons and several more which I outline below, over several projects that have all been run as Agile, I inevitably find myself developing a Sprint Roadmap.  A Sprint Roadmap is simply a projection of the remaining stories in the backlog, spread out over as many sprints as necessary to show how it all looks when they are laid out end to end, parallelized by how many dev and test resources you have.  A Sprint Roadmap is much like a product roadmap, except the items are at a story level rather than high level feature level, and the timeline granularity is sprint boundaries rather than calendar quarters. Also, and this is very important to consider and communicate, the items in the Sprint Roadmap are allowed to be un-estimated and un-sized.

You may be thinking – wait, isn’t that what story points and tracking velocity is all about?  The answer is yes.  In a perfect world, you simply score everything in the product backlog, prioritize it, then voila! you have your answer.  You can use your favorite Agile tracking tool to project how many remaining sprints and releases are required to get the backlog completed based on the current team velocity.  That’s one of the glorious things about tracking story points and team velocity, and here is an article that talks about using Jira to do that.

However, in practice, its not that simple, for a number of reasons:

  • If you are at the beginning of a project, you should have 100s of stories in the product backlog.  To estimate and prioritize all of them at the onset is counterproductive.  You need to get some momentum going and get some early wins by showing some working software as soon as possible.  This is where you need to get the engineers focused on asap, not on estimating the world of possibilities that likely don’t even have requirements fleshed out.
  • If you are somewhere towards the middle of the project, you by now have lots of deliverables under your belt, but also likely 1000+ items still in the backlog, because at this point the business is still happily adding new requirements regularly.  At this point you know your team velocity and you know what’s ahead of you in the foreseeable future, and you want your engineers to remain heads-down on delivering things, not diverting key developers and testers into a estimation exercise.
  • Whether you are at the beginning or the “middle” of a project, you would be hard-pressed to get the business to sit down and make the time to prioritize 1000 backlog items with you.  They usually at this stage will still want everything they ever asked for, and then some.  You’re own gut feel of where things are may tell you that there’s no way the project will meet the expected dates with all the functionality that the business wants, but you can’t push back and get the business to work with you to prioritize things on gut feeling alone.  You may have decades of experience with managing development projects, and you’re gut feel may be spot-on, but you need tools to help everyone get on the same page with the amount of work remaining.
  • At best you should only have the next 1-2 sprints sized up by developers and testers.  Having developers spend time on sizing things up beyond that is counter-productive because if you are working in an iterative fashion with the product owners, the product owners may not have fleshed out the detailed requirements yet, so spending developer cycles on sizing up development efforts for requirements that aren’t fully fleshed out can be an exercise in futility as they spin their wheels trying to chase down requirements rather than doing that actual sizing.  More on how to work in lock step with product owners in a cross functional squad model can be found here (insert blog link here when it is ready).

Notice that i didn’t say that a Sprint Roadmap shows when everything will get done.  It is not an accurate measure of that; It is most useful in showing when things WON’T get done.  This is because the key factor of a useful Sprint Roadmap is that it is not based on sizing and estimation efforts.  The sizing is done by the gut feel of the scrum master or dev lead, and its creation intentionally involves as little participation by developers as possible in order to keep them focused on their more immediate deliverables.

Mostly likely the sizing estimate done by the dev lead or scrum master will be less accurate than what developers closer to the ground would come up with, but that’s what you have to work with in order to move forward with a projection and still keep your team focused.  That’s OK.  The simplest approach is to treat all items as equal size and lay them out end to end by sprint in a spreadsheet.  Given that each developer will own a feature you can stick you finger in the wind and guesstimate how many stories can be put into each sprint based on team velocity.  I intentionally said spreadsheet because you don’t want to your agile tracking tool to get polluted with your unrealistic sizing.

As I said, this won’t tell you when you will be done, because the sizing you are doing for the stories aren’t very accurate.  However, it will reveal one enlightening revelation: that if you do everything that the business wants, there’s no way its all going to get done in the timeframe expected.  That’s the elephant in the room, folks, and it happens in every project.  Everyone on the team is happily flying along at 120 mph, and business owners and development owners alike are getting jazzed with excitement about how great this project is going to be.  You want to be the one who gets out in front of this and get the leadership team thinking more realistically about what can and can’t be done.  Using the Sprint Roadmap as a worksheet to force the conversation around prioritization and MVP between the Product Owners and the Development leadership is a great way to do this.  The sooner you all get to the table to talk about it, the sooner you can start having a productive conversation about prioritization and minimum viable product.