You've caught me; another blog about things that I have recently read.

The first is a note from Mike Cohn, who founded Mountain Goat Software. I don't, nor have I ever worked for Mike or his company. To be honest, I cannot recall how I first heard about him, but I've followed his blogs for years. He is a straight-shooter and calls 'em like he sees 'em. Most recently, he offered the following thoughts about estimation:

"I ask a team to estimate a product backlog item only when having the estimate will lead to actionably different behavior. So, for example, I might ask a team for an estimate on a user story so that I can decide if I want that story soon or perhaps not at all. Or I might ask for an estimate so I can make a commitment to a client or partner.

But I don’t ask a team to estimate just so I can later yell at them if they’re wrong. I don’t ask a team to estimate just so they feel pressure to meet that estimate."
(Yes, I know he's using some software lingo, but we all understand requirements, functionality and 'wish lists.' That's what he's talking about.)

I took a moment and thought about this. Granted, I'm frequently asked to estimate effort. We are all asked to provide estimates. But are these estimates used properly or, as Mike suggests, do they come back to bite you?

Maybe the article struck too close to home? On a recent project, I was hounded for a count of test cases. I have no problem telling anyone how many cases I've created, but if you aren't going to review them - and the requirements - the numbers don't mean anything. 'More' does not always equal 'good' (or 'better') in these situations.

In fact, it reminds me of the so-called 'good old days' of software where developers were paid by the line of code. Really. Have you ever heard of 'code bloat?' I assure you that many developers from that era have. Simply put, you cannot judge anything by the number of components. In other words, if 'some' is good, 'more' is not automatically better.

In his note, Mike goes on to add:
"Why not estimate everything?

Estimating can add a lot of value. It can lead to better decisions. For example, I’ll make a better 2016 budget with the estimates I’ve asked for than if I don’t get them. Right now, that’s important to me. But, if an estimate will not lead to an actionably different decision, time spent estimating is wasted."

He's right. You can spend a lot of time on tasks - estimating, metrics, even solutioning - that never come to fruition. His point is valid; if it means better decisions, it's not wasted time. And I would argue that sometimes we don't see better decisions coming from our efforts, and that can cause some frustration and even distrust.

As managers, we're often asking our teams to perform such activities. Sometimes we have to do them ourselves. Is the 'Why?' so hard to follow, or even question? Most of us can handle a situation once we have the appropriate information.

As Mike says, we can make better decisions. Working smarter, not harder, is the name of the game. So it's worthwhile to ask yourselves 'Why?' before requesting or performing the activity. If it leads to understanding and appreciating the goal, then it's time well spent. If you don't have a suitable answer, then you can determine that it's a wasted effort... and then the other questions start to form.

Because I cannot leave well enough alone, I also checked in with Johanna Rothman's site. I've referenced her work here before. She had a related but different topic recently, on 'resource efficiency.' Here is what she uncovered in a recent meeting with a client that was concerned about expertise and productivity:

"I want everyone fully utilized--how else will I know if people are productive?"
(This is a hot topic for me, particularly as a consultant. A freeway at full capacity, for example, means that no one is moving. Do managers really want that?!)

Johanna makes an important point in her note. "Measuring utilization is measuring effort. Your customers don't buy your efforts. They buy your products/features/releases. They buy the results of your efforts."

So estimation, measurement, expertise, utilization don't matter to your customer; make the best product and sell them what they asked for. Granted, pricing and delivery factor into the equation, but the message is clear. The buyer wants your best output, and you have to figure out how to deliver that.

Johanna concludes with this (a point that I agree with 100%):
"Use management to set the context and create an environment in which people can solve most of their problems. Measure the projects or features you finish, not the ones you start."

Your take-away is your own, and I suspect there are a few nodding heads in Reader Land. I tossed a lot of thoughts your way that made sense to me, but maybe not to you? Post your questions and thoughts below and let's see if we can get to a good place with estimates and measuring results. I look forward to the conversation!
Image credit: https://loribonfitto.files.wordpress.com/2014/11/raking-leaves.jpg

Tricia Simo Kush is a certified Professional Engineering Manager with a background in Information Technology and a goal to take her career to a higher level through Engineering Management. She graduated from the MEM program at St. Cloud State University in 2010. To her, Engineering Management is a fascinating mix of technology and business, people and process. She is constantly seeing the ways that Engineering Management spans industries and helps everyone to become effective leaders. Follow her on Twitter (@TSimoKush) or check out her profile on LinkedIn.