DEVOPSdigest

Two of the most daunting questions software engineers often hear are: "when will this be done?" and "how much will this cost?" Project managers and clients need to know these answers, but developers don't usually work in the same way where they can deliver certain answers to those questions. They often provide their best guess to those questions, only for the client to be disappointed when the project runs long or costs more than expected. But 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. Figure out what you know and what you don't

When first starting a project, have the necessary conversations to get all of the information you can from the client, or whoever is making the request. Ask as many questions as you can to understand goals and expectations. Find out what concerns they have, what their vision for the platform is, and anything else that could be important in the development process. It's fine if there are still some unknowns at this level of the process. 

Step 2. Build a User Story Map

After you have all of the information collected, start building out a user story map. This is a great way to visualize the roadmap of the work you'll have to do. This allows you to break down the product into manageable chunks and not get caught up in the small details. You'll want to include all the different stories and different personas using the product in this map. Then, outline each screen that needs to be 

Step 3. Assign values to your User Story Map

It is common in software development to either use effort estimates (hours/days) or story points to estimate work once it's broken down into a plan. But there could be other approaches that work better for your team. 

■ 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. Time to forecast

Now it is time to forecast. This can be done using several different tools, but 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.

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 a 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 this 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. You will also get a table with the likelihood of the project finishing on a specific date. This table is a great asset to have when asked that dreaded question: "When will you be finished?" 

Now you have something to budget and plan for. Keep in mind that it's always best to under-promise and over-deliver, so give conservative estimates. We all know things come up in software development, and sometimes things get off track, but forecasting tools take this into account. Your team can continue to 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.