Roadmapping

Once you’ve broken down a company initiative into epics and user stories, you’ll need to create a project roadmap that outlines the schedule for development.

You’ll start by estimating the time it takes to finish the project.

The difficulty of estimating a time frame

Estimating the time it will take to complete a feature is not easy.

Here’s an illustration:

Imagine that you drive a Ford vehicle, but your engine breaks down and needs replacing. You go to a mechanic who specializes in fixing Fords.

Your mechanic, who’s been fixing Fords for decades, can tell you right away how long it will take. Maybe it will take 6 hours, or 3 days. Either way, he can tell you immediately.

Now, imagine a different scenario, one in which everyone in the world drives a completely different car. In fact, each person has built their own unique car from things they’ve found around the house.

When you take your never-before-seen, custom-made car to the local mechanic to replace the engine, what do you expect he will say?

He won’t be able to tell you how long it will take to fix the engine. Not until he can get under the hood and see what it’s made of.

That’s how it works with software.

Engineers are the mechanics. Each code, system, database, and project is unique. In order to know how much time it will take to build a feature, they’ll have to do some tinkering to see how each piece of the feature is built before they can make a concrete estimate.

Sometimes things go extremely well, and the feature is finished ahead of schedule. Other times, something goes terribly wrong, and everything is set back.

In a nutshell, software estimation is very difficult.

Estimating a software project schedule

So how do you accurately estimate the schedule for a software-based project?

You’ll need to measure something called velocity. You’ll see what that means in a moment.

But first, imagine that you’re currently working on a sprint that contains 5 user stories. You’ll start by holding a Sprint Planning Meeting (also called a Scoping Meeting). This is where you’ll ask engineers how long it’ll take them to complete each user story.

Asking them for a time frame may produce an inaccurate schedule, for the reasons outlined above. The trick is to ask them, “How hard is it to do this?”

Have them rank the difficulty of each user story on a scale from 1 to 10 (10 being the most difficult). These numbers are called story points. Finally, add up the story points of each user story to get a total number of points for the current sprint.

Then file it away, and complete the project as usual.

At the end of the sprint, see which user stories you were able to complete within the time frame. (You may have to drop certain features if you run out of time before a release.)

In this case, let’s say you started with five items, but only finished three. However, those three had the most story points.

The velocity is the number of story points you were able to accomplish during the sprint.

Keep calculating the velocity for every sprint. Eventually you’ll get a good picture of how much your team can complete in a certain time frame. This is called the Average Sprint Velocity.

After that, you can estimate new products based on the Average Sprint Velocity. It’s usually rather accurate, just like our mechanic who’s used to working on Fords.

Building a roadmap

Every company approaches this differently. At its core, a roadmap is a schedule of each epic and sprint over the next few months or the entire year.

It’s usually very inaccurate. Why? Because if you’re working in agile, your requirements will always change based on current needs. You can’t plan out what you’ll be doing in upcoming months.

Then why spend time writing it out?

First of all, executives and investors like to see quarterly schedules, because that’s how they think.

Also, you’ll need to create a roadmap when there’s a very real deadline coming up, such as another team’s release that coincides with yours.

There is an alternative to time-based roadmaps, which takes the agile methodology into account. You’ll learn about this in the next lesson.