Every Product Manager has answered “yes” to at least one of these questions:

• Do you feel like you don’t know how much work is left to do?

• Do you have low confidence in estimating and fear missing a key deliverable date?

• Do you wish you had a visual diagram representing where you are in your development journey to pair with an architecture diagram?

If you answered “yes” to at least one of the questions, Story Mapping is a great tool that can be leveraged to provide insight to Product Managers and lead to improved software delivery estimation. Reliably and confidently estimating a software product delivery date is difficult for most. Even so, it is still a primary role of the Product Manager to drive the delivery of new features when the market needs them.

Story mapping is a valuable visual tool that arranges user stories in a way that creates a complete view of the overall user journey.  In a single graphic, story mapping shows you how a user interacts with a product, the activities and tasks that occur, and includes milestones that represent how and when you can iteratively deliver completed functionality that customers can use.  If you are new to story mapping, see the article “What is user story mapping?” to get oriented with this tool.

Throughout my career as a Product Manager, I have worked with engineering to estimate effort on both large and small projects.  I have tried methods such as adding a buffer to the original estimation to account for unknowns and t-shirt sizing, but neither approach improved the estimation. An even bigger challenge I had was not having clear insight into the work that needed to be done and where we were on that journey at any point in time. Recently, I decided to take a different approach of using Story Mapping to get one step further towards improving estimations and visibility into the development progress.  This provided both myself and the engineering team with the following benefits:

• Informs the priority and order of development execution

• Identifies gaps earlier in the execution phase

• Reduces the risk of under-estimating

• Fosters positive collaboration between product & engineering

To further illustrate how you can incorporate story mapping to improve your product delivery, I would like to walk you through a process I have tested and continue to fine-tune.

Step 1: Plan

Planning is critical to ensure success in your estimation process. You first need to understand what you are building, the scope of work, and the definition of done. Here are some tips to guide your planning process:

• Narrow your focus:  Begin by focusing on the milestone you defined and expect to deliver.  This is typically a complete set of features that make up a release to the customer.

• Create an implementation story map:  Now, it is time to go one step further and create an implementation story map. This should be a collaborative exercise conducted with your engineering team where you define the high-level work to be completed for each user story defined for your milestone.  See Figure 1 below for an example of an Implementation Story Map.

• Collaborate with engineering: Engaging your engineering team to create the implementation story map will increase the team’s ability to identify commonly missed work not usually considered during estimation. Here are some critical tips:

  • Clarify – Start by clarifying the “Definition of Done’ for the defined milestone.  You want to convey to the engineering team what the customer will be able to do at the end of the milestone.  Is the expectation to just be code complete, or are you expected to finish development and be live in production?   Be sure to consider some commonly missed work such as building CI/CD pipelines, functional tests, collateral (including end-user, developer, operations & client documentation), and non-functional requirements such as logging, auditing, performance, and security controls required for your organization.  These answers will all impact both your planning and estimation.

  • Define – With clarity on the ‘Definition of Done’, fill in your implementation story map by listing all the high-level units of work in priority order under each user story.   Your architect should have already created an architecture diagram that can guide the components and services needed at this point.  Next, you will want to slice your tasks into iterations based on both priority and dependencies.  These iterations can later be used in your sprint planning.

  • Validate – Remember to go back to your “Definition of Done” when listing the units of work.  Consider authentication, authorization, CI/CD, unit, integration & functional tests, load balancing for availability, auto-scaling for scalability, logging, metrics, auditing, and any other aspects needed to consider the milestone done.  As you go through this process and estimate, ask yourself critical questions like “has the team considered handling errors, returning client-friendly responses, retry logic, the complexity of the business logic, learning curve for new tools and/or technologies, and more?”.  Depending on your software development process, you want to ensure you include dependency teams such as your quality assurance team. This is a critical step that will help identify gaps in both planning and estimation, so ensure you ask these questions early and throughout your estimation and development process.

Step 2: Estimate & Forecast

With a plan in hand, you are now ready to estimate.  First, align with your engineering team on the methodology to estimate. There are a variety of estimation methods available and you should use the method most suitable for your team. Although I review the two methods below, you can replace these estimation methods with your team’s preference. The first method I will review is estimating by “number of tickets”.  This works best for teams that operate under a consistent process of “same-sizing” tickets and have a good understanding of the teams’ velocity. Same-sizing is used with teams that attempt to create tickets that generally take the same effort to complete, typically 1-2 days.  Alternatively, when there are more unknowns, then t-shirt sizing can be used. T-shirt sizing uses “relative sizing” by comparing the work to previous projects to estimate based on complexity, uncertainty, and effort to complete the task.  Below I will walk through forecasting examples using the number of tickets and t-shirt sizing techniques.

Forecast by Number of Tickets

• For each task in the implementation story map, align on the number of tickets you estimate will be needed to complete the task.  This can be accomplished using a collaborative poker estimation voting strategy with your team members (planITpoker is a free poker application that has great customization options).  It’s important to remember that this is meant to be an estimate based on what you know today, therefore a full detailed specification is not expected.  During voting discussions, focus on the goal of the task and the complexity, and remember to always go back to “Validate” in Step 1 to ensure you account for the definition of done.  Once voting is complete across all tasks, add them to get a sum of tickets necessary to complete the milestone.

• Estimate the projected end date using the total estimated number of tickets, your team’s average ticket velocity, and the standard deviation, which represents the spread of variability or uncertainty from week to week.  For illustration purposes, I’ve chosen to assume a weekly cycle but you can modify this to match your team’s cycle.  Be sure to account for team PTO and vacations.  Below is a burndown chart using a plot graph (Figure 2) to visualize how many weeks it will take to complete the milestone with an error bar representing your team’s standard deviation. Use the error bar to predict a range of the best, expected, or worst-case estimates assuming no change in scope. I included projections based on both the average velocity over the past 6 months and an average velocity over the past 4 weeks to apply a recency bias.  A recency bias would be important to consider especially if the team size or members have changed.

Forecast using T-Shirt Size

• Begin by leveraging your team’s t-shirt sizing process to estimate the size of each task in the milestone. T-shirt sizing can be measured in either days or story points, with both options representing a unit of time.  For this example, let’s assume t-shirt sizes equate to an estimated number of days.  Vote on each task and then add them all to get a total number of days to complete the milestone.

• Estimate the projected end date using your team’s average weekly capacity (in days) and an error percentage. Similar to the above, I created a burndown chart using a plot graph (Figure 3) to project the number of weeks to complete the milestone. The error percentage represents the spread of variability you expect to see on average based on the team’s delivery history.

Step 3: Execute

Now that you have a plan, an estimate, and the prioritized list of work, you are ready to execute and deliver.  A regular cadence of planning and tracking your progress will be essential to continue to refine your plan and mitigate risk early and often.  Conduct this planning in alignment with the engineering team’s development cycle, whether weekly, bi-weekly or longer.  In my experience, weekly or bi-weekly yields the best results.

• Planning:  Use your implementation story map to guide each week’s ticket-writing priorities. You can also keep this implementation story map updated and use it as a tool to communicate your progress.  Alternatively, migrating to your ticket tracking system (such as Jira or Rally) could be more efficient, depending on your process.

• Track your progress:  You can add another series to the plot graph to track your progress from week to week. In Figure 4 below, I have added the actual number of tickets left after each iteration. Doing this weekly will show you when you are off track so you can mitigate risk early.  In this example, you can see we projected 7-8 weeks, and the actual was 9-10 weeks.  Review to learn and pinpoint what is causing the delay.  Was it newly introduced work, under-estimation, personal time off (PTO),  or something else?  Discuss these questions in your retrospectives so you can continuously learn and refine your process.

• Mitigate Risk: This process, coupled with identifying new scope along the way or gaps in the initial estimation, will provide insight into risks to manage. The earlier you recognize roadblocks, dependencies, risks, and schedule delays, the faster you can mitigate, adjust scope, if possible, and raise awareness of potential schedule delays.

Step 4: Learn and Improve

Once you begin your execution phase, you should conduct regular retrospectives to learn what is working and what is not. Do not wait until the milestone is complete to perform a retrospective. Make it a part of your development cycle process to dive into the results of your planning and estimation. Ask questions and inquire about where the team hit the mark on estimations, where the team missed an estimation, and what was missed. There will always be some level of unknowns that will impact your project. The most common unknowns I’ve encountered were an unclear definition of done, missing high-level units of work, incorrect assumptions or dependencies, logic more complex than expected, technical troubleshooting, learning curve with new technologies, and not accounting for expected PTO. Each milestone you execute gives you an opportunity to learn from these unknowns to improve the process and execute better the next time. The engineering team will fully appreciate being involved in this entire process and I’ve received feedback they like how it shapes the picture of what we are accomplishing, the ability for them to participate early and often, and the clarity it brings to the scope and timeline.

In the end, it is a collaborative learning environment that will foster trust across your team, improve estimation, and identify gaps allowing you to regularly implement process improvements.  Remember, estimating is complex and it is not about being perfect; it is about continuously learning and improving.  Therefore, you want to foster an open and trusting environment where everyone can contribute to meeting your customers’ needs.  If you are new to estimating, I suggest you start with smaller projects such as proof of concepts (POCs) or minimum viable products (MVPs) to learn about technical implementations.  Follow the steps above and adapt to your team’s process so you can begin to learn to collaborate better with engineering to create better estimates and derisk your implementations.

Conclusion

There is no crystal ball to predict the future and estimation will never be a perfect process. The main goal of a Product Manager is to reliably deliver outcomes to our customers, therefore, we should do everything in our power to be better at delivering outcomes when we say they will be delivered. These lightweight processes discussed above can be incorporated to improve confidence, provide a continuous view of the development progress, and identify what was added or missed during the journey. Ideally, you want to develop a process that everyone buys into, improves over time, creates trust among the team, and yields positive results (i.e. more accurate prediction of software delivery over time). All this together will help identify critically overlooked or underestimated tasks and allow you to learn, manage and improve the estimation process to deliver customer outcomes with higher confidence.