LeadingAgile is Now LiminalArc. Read the Full Announcement

Move beyond isolated AI experiments to build scalable, domain-driven systems with AI-ready architectures.

Enhance valuation and accelerate ROI through due diligence, tech migrations, and strategic restructuring.

Control cloud costs, streamline data, and focus investments on high-value, scalable solutions.

Streamline operations and improve decision-making by aligning your ERP systems with how your business actually works.

Reduce risk and increase resilience by closing the security gaps hiding in your architecture and workflows.

Optimize operations, restructure teams, and modernize technology to maximize the value of digital investments.

Deliver mission-critical software in production-ready increments that create measurable value early.

Reduce risk and complexity with every cycle, turning legacy systems into platforms that can evolve.

The belief that shaped us — and how it evolved into LiminalArc, the natural next step in our journey.

Our team of over 100 experts spans the nation, from consultants and technical architects to product specialists.

We are looking to hire mature, pragmatic consultants who are deeply passionate about meaningful change.

Why Estimate?

Mike Cottmeyer Chief Executive Officer
Reading: Why Estimate?

Most people think about estimating as a way to figure out how big stuff is, so we can decide what we are going to build and when we are going to build it. More often than not, I find myself using estimation to help teams figure out what we are NOT going to build. Rather than create an IN list… I like to think about creating an OUT list.

Many of my clients are so overcommitted, they can’t have a conversation about focusing on a well groomed, prioritized product backlog until they come to grips with the fact that most of what they want to build just isn’t going to happen… at least not right now. Once they’ve got the noise out of the system, we can start breaking work down and looking at what might actually be possible.

Ever thought about using estimation as a way of committing to what we AREN’T going to do?

Next Agile Best Practices?

Comments (8)

  1. David Koontz
    Reply

    Yes! So many companies are doing too many things at once. Much of the work they do leads to partially finished work. So estimation is a requirement for them to prioritize.

    I teach Scrum workshops with a backlog estimated and prioritized into: Now, Next, Later.

    You suggest adding a fourth bucket: Never.

    I think I shall add that bucket to the wall chart. We always finish the workshop with items still on the wall (undone) – maybe this would help to make it clear we will not get to everything and some things we choose not to do.

    Reply
  2. Henri Hämäläinen
    Reply

    Totally! This is exactly the same thing I see estimation to be most valuable.

    Most often when guys start to talk about what needs to be done next, list goes on and on. Best way to make some sense to it, is to start estimating even in the highest level the items. Often already then people tend to notice that we have gone too far away and planning that far is waste.

    So I totally agree that important point of estimation is to learn what not to do, not what we are going to do.

    Reply
  3. John Fagan
    Reply

    Agreed too. I use MoSCoW prioritisation method, which gives you the 4 levels. But before I get the team to do this prioritisation, I get the team to do t-shirt estimates on each story (L, M, S).

    Anything that falls into the WONT bucket, is next rev (or never).

    Reply
  4. Agile Scout
    Reply

    Sometimes the best way of attacking an issue is figuring out what you’re NOT going to do first. Right on.

    Reply
  5. Isaac Sacolick
    Reply

    Mike – Great post. Amazes me how much push back I get from individuals and teams on providing estimates. I’ll elaborate more on my blog at some point, but I think you really capture the essence on how estimating drives critical decision making.

    Reply
  6. Dave Moran
    Reply

    I agree! It’s about value and trade-offs. The cumulative value of three features delivered in three successive sprints might very well have greater value than one, large feature delivered over the course of those same three sprints, for example.

    Reply

Leave a comment

Your email address will not be published. Required fields are marked *

×