Is SWAG a Four Letter Word? How to Get the Software Estimates you Need
You’re trying to get the executive team and stakeholders aligned on the long term strategy. Recently, the competition has been exploiting a product gap and sales wants to know when that can be addressed in the product roadmap. Meanwhile, your CEO has a new idea and wants to know how long it will take to build. What’s the ROI for the different options? One of the factors to consider when making these decisions is the effort, which you need to obtain from engineering. Does a typical exchange sound like this?Product: I need to know, when we can get X?Engineering: I don’t have time right now and I need detailed requirements and mockups.Product: But I just need a quick estimate!Good decision making requires good data. You need some level of effort and cost analysis to decide how to prioritize and sequence the product roadmap. However, estimates are not free. There’s a cost for the product team to develop requirements to estimate and there’s a cost to the engineering team to think through a design approach in order to provide an estimate.Engineering doesn’t want to give estimates that they might be held accountable for later and developing detailed estimates for requirements that churn or never get built is a waste. This is why getting estimates from engineering can be so painful. Using the right type of estimate at the right time can help mitigate the pain. There are different kinds of estimates for informing product strategy decisions, scoping the next release, and sprint planning. If done correctly, estimates are part of an ongoing conversation and continuous flow of information between product and engineering.
Avoid these 3 Common Pitfalls
Asking for Too Much Detail Too EarlyHigh-level estimates for product strategy should be done with as little effort as possible. The goal of this exercise is to decide what to work on and also what not to work on. The idea is to gather sufficient information to drive a decision and this can usually be done with engineering leadership. This might include the VP of Engineering, architects, or team leads depending on the size of your organization. Requirements can take the form of a bullet point list and a short description. The estimates are developed in meetings where product walks through a description of the requested functionality and engineering asks clarifying questions. The output is sometimes referred to as SWAGs, T-shirt sizing, or a term I like, “engineering opinions”. It’s not that these estimates are not fact-based, but it should be absolutely clear that these numbers should not be confused with actual commitments for scheduling.Waiting for Sprint ZeroIn my opinion, estimates for release planning are the most critical and ones that many organizations get wrong. By this time, you have a prioritized set of features and business goals established. The product team is trying to evaluate feasibility and scope in order to deliver a good MVP within the development cycle. Typically, engineering is busy implementing the current sprint and you try to manage the release planning like a baton hand-off in between releases during some kind of a sprint 0.An alternate, more effective approach is to bring the leads of engineering, QA, and UX into the process earlier. It’s not just about estimating, but reviewing requirements. By investing short periods of time over a longer duration, you can reduce requirements churn, which leads to higher engineering velocity, fewer unexpected surprises during implementation, and a better probability of delivering on schedule.Schedule weekly meetings to review and refine the latest iteration of requirements. If you have dependencies between multiple product teams, this is also the time to identify those dependencies. Over time, you’ll have a process of osmosis where product conveys the desired functionality so engineering understands why and not just what. Through this exchange, engineering often identifies requirement gaps and sometimes an alternate, less costly approach. UX refines their mockups and prototypes. There’s time between the meetings to do follow-up research so each meeting is productive.Pushing for Lower EstimatesWhen you’re ready to start the next release or sprint; engineering and QA leadership can drive the estimates for sprint scheduling because they’re already been immersed in the requirements. At this point, stories are broken into technical tasks and assigned story points. Engineering is typically measured on velocity and ability to deliver on time. There is great sensitivity to missing deadlines and the temptation to pad estimates. One way to avoid this is to have a buffer. Assume that 20% of estimates will be over and you’ll be right 80% of the time. One method that we’ve implemented to continuously improve estimates is to review the accuracy after each sprint. We drill into to the reason for estimate deviations outside a % threshold, both over and under-estimates. This helps improve the predictability of the schedule over time.Good luck with your SWAGs! Have any questions? Follow a different process? Please share your thoughts.
Janet Lee is the VP of Products for Lattice Engines and is responsible for the company product roadmap and is the driving force behind the development of Lattice’s pioneering predictive technology. Specializing in SaaS, predictive analytics and CRM, she has a proven track record of bringing products customers love to market. Prior to joining Lattice, Janet led the product team for all of Oracle’s Retail Optimization applications. Prior to Oracle, Janet held senior level positions in product management at enterprise software companies Frictionless Commerce (acquired by SAP) and Marcam (acquired by Invensys).Janet earned a Bachelor’s degree in Economics from Brandeis University. She is a co-inventor on a patent for “A System and Method for Real Time Activity Based Accounting (7,685,029).