Project estimations are tricky.
We’ve all had those experiences: a tiny ticket taking two weeks of work or a developer completing a seemingly complex task within an hour.
The truth is, detailed estimations are not only inaccurate but also very time-consuming. Yet, it’s hard to make any sound decisions without having a basic grasp of how complex a given initiative might be.
This is where rough order of magnitude (ROM) planning comes in.
A rough order of magnitude (ROM) estimate is a preliminary, high-level estimation process.
The goal here isn’t to give a concrete answer of exactly how costly a given initiative might be, but to give just enough details to facilitate proper planning and decision-making.
We use ROM estimates for:
For fully fledged, detailed estimations, you need either a well-described product requirement document (PRD) or a product backlog. For ROM estimates, that’s not the case.
The goal here is to give a high-level assessment quickly without investing too much effort. Yet, you still need to base your estimates on something, right?
The most common inputs for ROM estimates include:
A picture says 1,000 words.
Although you don’t want to spend excessive time preparing a fully fledged design — especially if you still don’t know if you will pursue the idea — preparing some initial wireframes can help tremendously:
A wireframe shows the team what they might expect from the final design and what functionalities they need to build, giving them a tangible playground for discussions and conversations.
A user flow diagram is a visual representation of the steps a user takes to complete a specific task or reach a certain goal while using your product. It maps out the user’s journey, highlighting the various touch points and interactions they have with the product.
User flow diagrams make it easier to show what those particular steps look like, including edge cases and the range of possible ways a user might interact with your app.
Such a diagram might be as high-level or as detailed as you prefer. You might get super specific or stay at a high level, depending on your time constraints.
These diagrams are especially useful if there’s a lot of work that happens in the backend or asynchronously that cannot be easily visualized with wireframes.
And last but not least, you might want to invest some time creating high-level themes and epics:
An epic is a feature or functionality consisting of multiple building blocks and scenarios. Epics are derived from themes or initiatives and can be segmented into smaller pieces called user stories.
An epic can span across multiple sprints, teams, and even projects. The theme, epic, and user stories share the same strategic goal at different levels of the focus area.
These serve as high-level documentation. Once again, depending on your time constraints, you might be as general or as specific as needed. Still, for rough order of magnitude planning, we usually aim for simplicity and fast answers.
There’s no strict rule on how long rough order of magnitude planning should take. You might need to provide a high-level assessment in an hour or so, or in some cases, you might have a whole sprint to come up with an answer.
Depending on the complexity of the initiative you are estimating, and the time you have available, you might want to use more than one input to understand the topic at hand better.
As a rule of thumb:
In theory, the rough order of magnitude planning includes both the time and cost of a given initiative.
However, we usually treat these as the same thing in product management. Because the biggest cost is the team, the more time-consuming an initiative is, the more costly it tends to be.
For a high-level estimate, don’t aim to estimate hours or even man-days; it’s too detailed at this stage.
There are three common high-level estimation techniques:
The idea of t-shirt sizing is to break the initiative into a few chunks of work and estimate them separately, usually using time units.
For example, your t-shirt sizes might mean:
You then estimate every chunk of work, be it individual wireframe screens or separate epics, and combine the final result into one estimate.
Sprints are similar to t-shirt sizing, but instead of using time ranges, you give a high-level assessment of the number of sprints the initiative will take.
It often helps keep the team more grounded in reality — sprints are more tangible than general units of time — and simplifies the process — instead of overthinking if it’s three or four weeks, you just put a higher number of sprints.
Although most of the team should use small story point estimates, such as between 1–8, story points can also be occasionally used for higher-level estimations.
For example, if you have delivered a ticket estimated for 21 story points in the past, you can now compare the complexity of the epics or screens based on that ticket. Do you assume the work will be thrice as complex? Then 60 story points it is.
You can then compare the sum of story points estimated to your average velocity to assess the time needed to deliver the initiative.
High-level estimations tend to be…inaccurate. More often than not, we are either too optimistic in our estimations or miss crucial details that might slow us down or require additional effort.
In short, we tend to underestimate the work. Although overestimations also happen, these are more rare.
If you want your estimate to be more realistic, adjust the boundaries of your estimates by lowering the most optimistic estimate and increasing the most pessimistic estimate. The most common approach is to use a -25 percent and +75 percent approach.
That means if your initial estimate was, say, between 10–14 sprints to deliver an initiative, then:
As a result, your adjusted estimate is between ~8 and ~25 sprints. Although it is much wider (thus diluted) than previously, it also gives a more honest picture of the worst-case scenario.
You might adjust boundaries by as little as 10 percent or as much as 100 percent, depending on the effort you’ve put into your high-level estimates. The more thorough the initial estimate, the smaller the adjustment required.
Now let’s see how ROM estimates can help you make better decisions.
If you have multiple, seemingly great ideas for your product and can’t decide which ones to pursue, you should start with high-level ROM estimates. That investment will help you avoid the cost of making the wrong choice.
The process looks something like this:
Based on those rough estimates, re-assess all the ideas and choose the ones with the best impact-effort ratio. Then invest additional time to make more precise estimations.
This framework should help you reveal a clear winner without investing time to do a detailed estimation of all your initial ideas.
Rough order of magnitude estimations and planning is one of the core techniques to prioritize initiatives, assess budget, and plan timelines.
Although the name itself might be daunting, in reality, it just means “high-level estimations.”
Building a culture of quick, high-level estimations within the team is essential. This will reduce the risk of committing to excessively complex ideas and maximize the chances you will find the best impact-effort solutions.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Karen Letendre talks about how she helps her team advance in their careers via mentorship, upskilling programs, and more.
An IPT isn’t just another team; it’s a strategic approach that breaks down unnecessary communication blockades for open communication.
Learn more →
