Estimation Spreadsheets That Map Resources

Problem

So far this year, my company has had a lot of large redesign projects happening at once. We realized, though, that we made some classic mistakes that most product teams are guilty of. At the beginning of the year, we came up with a really ambitious plan for all that we wanted to accomplish. We set timelines for the plan but by the time we got to the implementation phase, we discovered that we actually over-committed ourselves to what we originally said we were going to build.

Actions taken

To try and prevent this from happening in the future we put in place a new process. As we are approaching the next sprint or phase of work that needs to be done, both product and engineering sit down together and break down everything component by component. For example, let's say there are three different products or services that need to be redesigned. Product and engineering will go through every platform and break down exactly what needs to be done. We look separately at web, mobile, iOS, and Android and state the exact components for each, almost down to the user story. Then we make estimations while accounting for all of our resources. Essentially we are creating estimation spreadsheets. The spreadsheets are organized as such:

• Each row will represent a single component.
• A screenshot is provided in one cell.
• Another cell will include details that the engineer should know in order to get them to understand the general functionality.
• Then there is another row that establishes the person that will be assigned to that work.
• In a separate spreadsheet, we take all of the components and perform our estimations exercise. This particular piece helps us manage a conversation around whether we are going to hit a certain date or functionality on a per-platform basis. Depending on the resources, the estimations for each platform will be different, and that's okay. As long as everything is effectively communicated. This estimation exercise is usually performed 2-3 weeks before we want to start working on something. We are constantly replanning so it's not efficient to plan too far in advance, otherwise, we'll have to go back and change the plan. The process is pretty tedious but it helps us identify gaps, what we are doing to make up for those gaps, urges us to move resources between teams, or to make cuts if something is not convincingly achievable at that time.

Lessons learned

• The estimation spreadsheets should be separate from your product roadmap. I think that if you were to put everything together it would be monstrous and bewildering. Instead, first, devise a high-level roadmap that gives a general idea of all the work that you will be doing over the span of a certain time. Then product managers and engineers should spend time together to create really detailed estimation spreadsheets that break down component by component everything that needs to be built.
• The audience for this type of documentation is typically only the product development team. These are internal artifacts that you are going to use to do your own planning and to make sure that things are getting done. No one beyond this team should be viewing these estimations.
• Not all of our estimates are correct. In the past couple of months, we have been working on some things that we underestimated and working on other things that we overestimated. We also tend to do a lot of things that aren't in the estimate, that wasn't planned - like changing designs last minute, but that's the classic tension of product development.
• Start with a vision of where you want to get to and then work backward thinking about how you are going to break that down into milestones. Then you can theme each of your milestones. For example, this particular theme is part of the user journey or this area is part of the product. Then you can sequence your work and reduce the risk of having to do massive changes all at once.
• When constructing the final product due dates and milestones, my preferred method is to take a high-level goal approach. Set initiatives that you want to accomplish in the next six months and set out to solve those problems. This is in contrast to trying to ship A, B, and C within those six months. I think this type of user-centric mindset is better for a product development team rather than an output-centric mindset.
• I've found that the company I work for has a very unique way of working in that our product development philosophy is based on a visionary ideal state. So we usually start with a design, the ideal state, but quickly consider the reality of the resources we have on the team today to achieve that vision. Then we cut things off of the ideal in a negotiating manner with leadership. This is a helpful process that allows us to understand how much we can take on with the resources that we have.