smartObjx
Home
smartSaaS Bundled platform with all core services
smartRules Enterprise rules management with IDE & versioning
smartStructures Organizational hierarchies with multi-perspective views
smartSettings Nested SaaS configuration per customer & org
smartProfiles User preferences and profile microservice
smartConnectors Domain-driven NuGet class libraries & SDKs
smartAccess Security management & permissions for SaaS
smartBlogs About Contact
← Back to smartBlogs

Estimating is a Skill

Russ McClelland · December 13, 2022

Developers often push back against providing estimates for features. I have to admit that as a developer, I was guilty of pushing back at times. Product Managers often say they can’t do their job without estimates. I have to admit that as a Product Manager, I’ve asked teams to provide estimates. As a consultant, I’m often sandwiched between these two positions and need to find some way to move forward.

One friction point is that there is not always a common definition of what an estimate is. Both parties need to trust each other. An “estimate” is not an “exact”, and it never will be. Product Managers, don’t force teams to work unreasonable hours just because the estimate was “wrong” and you will likely find less hesitation to providing estimates. Developers, don’t give a single number for your estimate and you will give the business a way to build in some risk management. Instead, give a range such as “3-5 sprints for the stories requested.”

Another friction point is that many developers, of all experience levels, don’t know where to begin. I like to begin with our architecture. Does this story require changes to the:

  • UI?
  • API?
  • Domain libraries?
  • Database schema?
  • Unit/Automated Tests?

Then I add other activities related to the operational aspects. Do I need a script to modify existing data in tables because the schema changed? Is that a long running process that also needs an “engineered” approach? Do I need new components or services that require DevOps activities? Infrastructure components? Manual Testing? CTOs and Architects, do your teams know what your architecture is? If not, you can help your teams estimate and build better software by documenting and clearly communicating your platform architecture.

Is this process perfect? No. It’s not supposed to be. It’s an estimate. I see a lot of Agile experts say you should never need to estimate. They say you should cut stories into pieces that are big enough to implement in 1-2 days. That is an estimate. But there is never a process for “how” to get there.

Does this process take a long time? No. I typically have teams set a 5 minute limit to how much time they can spend estimating a story. Having the timer visible on the screen helps people focus. Can they do that in our first attempt? No, but we can get there over time, because estimating is a skill, and just like any other skill, you can get better with practice…

smartObjx

Powering SaaS companies.
You focus on business value, let us focus on infrastructure.

Products

smartSaaS smartRules smartStructures smartSettings smartProfiles smartConnectors smartAccess

Company

About Blog Contact

Connect

info@smartObjx.com

© 2026 smartObjx, LLC. All rights reserved.

Terms of Use Privacy Statement