Why We Don't Do Detailed Planning For Long-Range Work

We do not do detailed planning for long-range work.

Your team has been discussing a great new feature with some stakeholders. Everybody is really excited until… the question that every engineer dreads…

So when can you have it done by?

For the stakeholders, it’s a simple question. You’ve convinced me that we need this feature. I’m excited about it and want to promote it. To do that, I need to know when I can expect it. For the engineers, deadlines are loaded questions. Software development is inherently difficult to estimate. Similarly, any good feature can and should change during its development which can impact its delivery date. Depending on the culture of the team and the organization, missing a deadline can have significant impacts.

Stefan, is the product manager on a cross functional product team. He believes the best way to satisfy his stakeholders is to provide them with a detailed plan of when his team will deliver their work to production. He sees this approach as a risk reduction strategy. By establishing a strict plan, he can guarantee that there isn’t any miscommunication between him and the stakeholders. One of those stakeholders is a sales representative who is planning to communicate Stefan’s timeline directly to current and future customers in order to get new business and drive renewals.

Needless to say, this approach is very alarming to the engineers. Not only is Stefan trying to lock them into a specific delivery timeline but by sharing the plan outside of the organization, there’s even higher pressure to stick to it. In order to build out the timeline, the team will need to estimate the work. There is a direct correlation between the accuracy of the estimate and how long generating that estimate takes. However, even if the team spends weeks estimating, they still won’t be able to eliminate all of the risks and create a perfectly accurate estimate. Estimating has its own opportunity cost as well, time spent estimating could be spent working on actual features. Specific plans with fixed scope have business implications as well. Stefan’s approach works both ways, preventing the stakeholder from changing the scope as the team is working.

Some organizations go as far as requiring stakeholders to physically sign a scope document before the team begins working. This lack of agility prevents business leaders from responding to market trends. Finally, a project management concept known as the iron triangle plays a role as well. In this concept, scope, resources, and time make up a fixed triangle. You can only make limited changes and each time you lock down one of the corners, the others must flex to accommodate that change. In Stefan’s scenario, both time and scope are fixed so only resources can be adjusted. This can mean adding an additional team to the work, asking the team to work more hours, or sacrificing quality to deliver on time. None of these options are great and all have risks associated with them.

Pluralsight believes strongly that this degree of inflexible planning is detrimental to the health of our product teams and does little to minimize risk to the organization. The most valuable use of our product teams’ time is working on their product. Lengthy estimation sessions are a distraction from that work. At the same time, we recognize the need for product leaders to have a degree of predictability. With that in mind, Pluralsight relies on a more flexible model of estimation. Product leaders present priorities structured in a “now, next, later” format with quarters representing the time increments. This approach allows teams to focus on “now” work, with minimal distractions by the “next” and “later” work. For estimations, teams only need to answer whether or not the proposed functionality would fit into a quarter or if it’s too big. The descriptions of these initiatives are very high level. They might be something like “make learner data available to our customers” instead of “provide a full extract of learner data via JSON API that uses OAUTH to secure requests and provides full audit logs.” Notice the difference between the two statements. The first allows the team including the product manager to adjust to new technical or market information. The second does not. If Pluralsight and the industry at large decide to move to GraphQL rather than JSON, the team can’t pivot. Similarly, if the product manager determines that auditability is no longer a critical requirement, the team must still build the functionality anyways. Of course this example is a bit hyperbolic but it serves as a good illustration point.

Ultimately, the statement “we do not do detailed planning for long-range work” is about striking a balance between specificity and flexibility. Business stakeholders need a high level of detail about what new functionality will be available for customers at roughly what time. Product teams and stakeholders both need to understand that scope can and should change as feature work progresses.

Checkout our Engineering at Pluralsight document to see all of the statements that shape our engineering culture.