Estimating A Software Project With User Story Mapping

By Adam Scroggin, CardBoard

Estimating a software project can be a dreaded task for software engineers. In the business world, people love certainty; they want to know how much something will cost and how long a task will take to complete. But software engineering does not work that way. If you’ve spent any time in software development, you’ve probably experienced the fallout of providing your best “guess” and having it held against you as a commitment. Luckily there is a better approach to budgeting for product updates: user story mapping and forecasting.

User story mapping is a way for product managers, developers and designers to put structure around product design and create an excellent user experience (UX). If you are approaching a new product update and need to plan ahead, here are the steps to take.

Step 1. Collect What You Know (And What You Don’t)

As you get started, you need to have conversations to collect all the information you can from the people making the request. Ask as many questions as possible to understand the goals and expectations they have for the product. What concerns do they have? What is their vision for how the platform will look? You might end up with a requirements document in your hands, which is a good start. After you read it, still have the conversation. It’s okay if there are still uncertainties (risks) at this level.

Step 2. Build A User Story Map

After you get background information, you can begin to build out a user story map, which is a great way to visualize the work ahead of you. This allows you to break down the product into manageable chunks and not get caught up in the small details. Work to gather all the stories of your different personas using your product. Next, outline each screen that needs to be developed. Now you should be gaining an understanding of what needs to be built.

Step 3. Sizing And Counting

It is common in software development to either use effort estimates (hours/days) or story points to estimate work once it is broken down. There are a couple of approaches that can work better: t-shirt sizing and counts.

• T-shirt sizing: look at each task and assign an estimation value. For example, small, medium and large. This is a great way to simplify without numbers. Instead, each task gets a size based on how it compares to the other tasks.
• Counts: assume each task is roughly the same size. So you count the total number of tasks and multiply by some factor to get the estimate. The reality is a majority of products will average out to a certain number with a little variance if you can break them down into understandable pieces of work.

Step 4. Forecast

Now it is time to forecast. This can be done using several different tools. Your best bet is one that runs Monte Carlo simulations to provide a date range of when you will be done and assigns a certainty to each date. Here’s one tool from Troy Magennis.

To begin your forecast, start with some key metrics:

• Start date - when you think you’ll begin
• Low guess - count the number of stories in your user story map
• High guess - include contingency for rework, bugs and risk that materializes
• How many days are in your sprints?
• A low and high guess for how many stories you will get done in a sprint

After you enter the data, the tool can run simulations of the project and collect the different outcomes. You will end up with a histogram of the number of times a simulation finishes on a particular date. In addition, you will get a table with the likelihood of the project finishing on a date. This table is a great asset to have when asked, “When will you be finished?” The key is to communicate a range of dates where you might finish the updates. It is typically best to avoid using any dates with less than 50 percent likelihood. Most projects will finish in the 50 to 90 percent range.

Now you have something to budget and plan for. It is always best to under-promise and over-deliver, so give conservative estimates. We all know things come up in software development. Something will not go your way, but it’s okay because the forecasting takes this into account. You can update your user story map as you learn more and feed that information into your forecasting tool.

Just like weather forecasts change, forecasting for your software project will change. Don’t give a single date from the onset. Instead, provide a range and update it as things change. Keep the team informed by communicating your forecast. Once your customer has an estimate, you can get to work on the fun stuff - developing the product.

About The Author

Adam Scroggin is the CEO of CardBoard, a visual collaboration platform that helps teams visualize their work with a focus on user story mapping. Adam has been building software products for nearly two decades and believes that understanding customer problems and validating solutions is key for building successful products.