Rough-Order Sizing: Bigger Than A Sprint Estimating

Sizing and estimation of work is a recurring point of conflict for Software Development teams. Executives, Project Managers, and Product Owners continually ask for them. “They are only estimates; you’ll not be held to them or blamed if you don’t meet them”. Software teams try to avoid them because they perpetually get asked “Why were your estimates wrong”. Different methodologies have different processes, but most include some attempt to gauge scope, level-set expectations, and provide some framework to measure progress. Whether gauged as task-hours, man-months, story points, team-weeks, or some other direct (or abstract) unit of measure, all seek to introduce predictability and measurability into future outcomes clouded by uncertainty.

Because humans have a clearer perspective of things occurring now and across smaller time spans, Agile methodologies introduce a compromise for this conflict by focusing their sizing & estimation efforts into small time intervals (called Sprints). Variance in estimation (often gets mischaracterized as “inaccuracy”) is the smallest for things we are actively thinking about and working on now. Unfortunately, estimating over short intervals offer little insight into scope and schedule for work performed across a longer timeline (i.e. multiple Sprints, a Product Release).

Why Estimate For Releases?

If I ask you for X, how much will it cost and when can I expect to get it? No one would go to a car dealership to buy a new Honda and leave a blank check on the promise that their new car would arrive at some future date with some whatever variable set of attributes that they are able to finish. It is altogether reasonable that someone would want to know what they will get for their money!

On the flip side, most software projects lack a clear definition of X at the stages that Development teams are asked for estimates. It is unreasonable to expect a clear, concise, and accurate answer to a speculative question related to activities to be performed at an undetermined future time.

Without returning to the time-intensive “phased” approach to software design and estimation, can Software Development teams give cost and schedule insight in the form of estimates to customers or leaders with budgetary responsibilities? Can we craft an effective compromise?

Yes (With This Agreement)

“Accuracy” of estimates can never be used for “metrics” if someone wants Software Development teams to provide them. If you want something to measure and you chose “accuracy” of estimates, be assured that teams are going to avoid providing them. Every technology professional with any level of experience has been asked for estimates and told that they would not get “beat up because we know they are estimates”. Invariably, nobody who makes that promise remembers it mid-project when charts and timelines highlight that the project is “behind”. During a project or at the end during an Executive Review, the first question on the list becomes “Why were the estimates so bad”.

If Software Development teams are unwilling to provide longer-range estimates or estimates for larger-scoped requests, it is likely one of two issues:

• Skill (“Can I do it?”)
• Trust (“What will happen when I’m ‘wrong’?”).

If a team’s issue is the skill or capability to provider longer-range estimates, read on below for details on how to develop it.

If the issue is trust, why has it not been earned? Have there been behaviors now or in the past that breached the trust? What things need to be done to re-establish it? (Here is the reality: Estimates, made without complete details, are never “right” or “wrong”. Actual results are simply higher or lower than original estimates. If you are not willing to accept that reality, stop here now because you are not going to get the results you seek.)

What is Rough-Order Sizing

Rough-Order Sizing definition – An estimating model allow imprecise scoping of work items within a Release that have not been decomposed and groomed for scheduling within an Agile Sprint or Iteration.

Using construction as an example, it is the difference between:

1. I want a house on a farm.
2. I want a rural farmhouse with 4BR nearby where I currently live with enough acreage and a barn where I can have some chickens, goats, and maybe a cow.

Item #1 is simply too nebulous for any expectation for an estimate. Item #2, while not specific, offers a much clearer framework from which a ranged estimate can be developed.

By utilizing a Rough-Order Sizing process, teams can form a more predictable, estimable scaffolding around abstract, unknown requirements. With it, Product Owners and Delivery Teams can more effectively layout the scope of work that can be delivered within a Release.

For teams that already utilize some form of relative sizing for their Sprint planning, Rough-Order Sizing simply represents larger and more-imprecise ranges that can aid Release Planning for work performed across multiple Sprints. See below for examples where Sprint-level sizing might relate to Release-level (Rough Order) Sizing:

• Power-Of-Two (2ⁿ): 1, 2, 4, 8, 16, 32, 64, 128
• Fibbonaci: 1, 2, 3, 5, 8, 13, 20, 40, 100
• T-Shirt Sizing: XS, S, M, L, XL, 2XL, 4XL, 6XL

Note: For Agile teams who follow #NoSizing practices, some form of Rough-Order Sizing can provide an agreeable compromise to Product Owners and Executives who hold budgetary accountability.

Rough-Order Sizing attempts to ease the conflict at Budget or Planning time providing insight for scheduling and resource requirements while acknowledging that future events, competing objectives, and details of requirements and / or technical implementations are unclear.

Nuts-And-Bolts

Often, Epic features or new application ideas are the result of a passing conversation or email. Items are presented as little more than visioning with no common understanding. For budgetary or Release Planning scenarios, they are too unbounded and lacking substance. However, to roughly estimate, we need have neither all details settled nor all design decisions settled. There just needs to be enough scaffolding that everyone can see the basic outline and a Development team can offer a “guesstimate”.

First, work with your team to decompose the epics or application ideas into component pieces that can be more effective scoped and sized.

Decomposition – Separation of an item into simpler, more basic elements.

Decomposition is the “secret sauce” to Rough-Order Sizing. It is an exercise that takes larger, more generic ideas and breaks them down by components and then into smaller, more familiar actions and behaviors. When decomposing epics to the component level, most questions are based on identifying: What is affected? Once components are identified, the request is further broken down by the required actions and behaviors answering: What does it do? The end result becomes more recognizable and familiar units of work that a Software Development team can size, estimate, and deliver.

From the example above (“I want a house on a farm”), here are some questions that one might ask:

• Where would you like to live?
• What type of houses do you like? What do you like about them?
• How many people will live in the house? Are there any specific things about the house that you expect?
• Are there other uses of the property that you need or expect?
• When would you like to move?

Note: For each of these questions, asking “Why” they have that desire will provide deeper clarity and context.

Within the span of 10-15 min, one can often move from an unbounded, amorphous “wish” to a request that can be sized to a rudimentary detail.

The process works equally well when dealing with software.

Consider the following: “I want customers to be to view my products via the web.” Most everyone has interacted with multiple online catalogs (including the requestor). A similar questioning strategy can quickly move from this more-generic to a much better-defined request.

• Do you already have a website? Upon which platform is it based? Does that platform have plug-in capabilities that meet your need?
• How many products are you displaying?
• Are you expecting a product listing and a product detail page? How many photos do you expect to include?
• Are you displaying your products or do you intend to sell them via the platform?
• Do you expect the catalog to provide inventory & fulfillment information?
• Do you already have a list of customers or are you planning to enable registration?
• If you expect to manage payment, do you handle it or utilize an external service / API?
• How do you plan to manage the product list?

Based on these basic questions, we can determine whether this effort could be on the order of setup / configuration of a WordPress plug-in or creation of an entire web application or enhancement to an existing web application. Even without exact details, the framework for the required work begins to take shape.

Finally, we should review original estimates versus actual results after the fact. The objective should not be focused on calculation of metrics related to the difference, but identification of how teams can get more on target with their estimating. Again, the goal should not be determining whether estimates were “good” or “bad”, but improving them to make them more informative to external audiences. Remember that the quickest way to train teams to avoid estimating is to identify it as some measure of performance. Software Development teams can no more predict detailed time estimates over the span of months and years than Product organizations can predict evolution of customer requirements over that period. Change is a certainty; predictions of the outcomes that change will bring about are not.

Actions

The best way to develop a new skill is to try it; the best way to improve an existing skill is to practice it. Follow these simple steps to develop your team’s capability to estimate work over longer horizons.

1. If you have damaged trust relative to estimating and actuals in the past (or a predecessor has), work to repair that relationship. Acknowledge the mistake, apologize for it, and explain the framework being put in place to get better results the next time. (Be sure to follow through on your commitments! This could represent #OneSmallChange in your behavior that produces tremendous results!)
2. Add scale to your existing sizes for work at a scope greater than your normal sprints
3. Select one or more candidates for Rough-order estimation
4. Compare actuals versus estimates and identify ways to improve
5. Add feedback below (or reach out on Twitter @SwamiDaveSays) for questions you may have or results that you and your team have achieved