Feb 082012

Padding can throw off coordination

A few days ago, we uncovered an opportunity that depended a lot on timing.

If we could get it going in five days, we could exploit it… if it took longer than that, the timing was going to impact some other strategic concerns.

I asked a developer for an estimate of the effort, and he said it would take ten days to complete.

About my own estimates

I have always been sensitive to suggest my own estimates to other developers.

My estimates nearly always scared others, but I had a pretty good software career built on hitting them.

Meanwhile, I have seen many projects run into the ground from estimate padding, being 85% complete for weeks on end and struggling to communicate status or progress until they ultimately failed.

Back to our hero

So, I asked him to drop that initiative and refocus on another work item because we just weren’t going to deliver in time.

And his reaction was like I had hurt his feelings. He had gotten interested in producing the estimate and really wanted to do the work.

I explained to him the timing concerns, and what happened next???

He started negotiating his own estimate with me!

Well, that was a conservative estimate.

I want to make sure I have the time to do a quality job and test it.

That was really an external estimate, meant for people outside of IT.

It might be more like five days than ten.

And after all that negotiation, I said “Thank you for explaining this to me… please work on that other thing.”

Promises, promises

I don’t spend a lot of time thinking about what other people think estimates are.

Pinky-shake a promise?

To me, an estimate is a promise. It is a commitment. It states my intention. It is the beginning of an offer.

When I estimate something will take 10 days, I am saying “If you accept my estimate, I commit to do this in ten days.”

Now, if I need something done in five days, then an estimate that says it will take ten days is not valuable to me.

If I truly have only five days to get it done, then an estimate of ten days is not even relevant to consider.

As I work with my teams, they get to know that about me, and the amount they pad their estimates starts to go down… especially if they really want the most interesting and challenging opportunities.

Actually, one of the ways I can build trust with my teams is by declining their offers that aren’t valuable… and quickly accepting those that are.

Estimates and trust

Since estimates have a lot to do with promises and commitments, you can expect if you have read my writing that they are also a foundation upon which to build team trust.

There are many cultures in which estimate padding is a common practice for self-defense and just-in-case management. Where “demand management” is also commonplace, the combination can lead to poor overall throughput from IT.

It is a practice born out of fear of reprisal, and sometimes out of fear that managers will disrespect how long it really takes to get something done.

So if you are working to build an organization or team in which trust is an important virtue or value, estimate padding might be something you want to address… and to do that you might have to look at cultural and management practices that compel people to do it.

If this topic is valuable to you, you may also be interested to read about having the courage to act, or how we are not victims of circumstance.

  21 Responses to “Padding estimates and promises”

  1. In Scrum at least, an estimate is _not_ a promise. It’s the best guess that the team can come up with to complete a story and no matter how much time is spent on estimates they will likely be wrong anyway. I would say that if you treat the estimates as promises you are more likely to get padded estimates since everyone wants to be on the safe side.

    • Thanks, Frede.

      That is fair. I don’t look at the points we assign to story cards as the kind of estimate I am referred to in this case. My team actually uses a kanban system for custom development in which we measure cycle time and don’t estimate cards at all… at least for flow purposes.

      In this case, I needed a quick decision as to whether we could hit a deadline outside of a normal stream of work… would we chose to take on the additional “opportunity”. When the estimate came back suggesting it couldn’t fit in… the decision was whether or not to jump into the work.

      When a go/no-go decision has to be made, a little bit of padding can mean we turn away from the opportunity.


  2. Hi Ken,

    After reading your post, I was wondering if the developer would have provided a different answer if you asked for a promise or commitment instead of an estimate. Or, and maybe you did this, explain to him what you meant for when asking for an estimate. In other words, do you think that his understanding of what an estimate is or would have had an impact on his response?

    Based on his response when he started negotiating with you, I also wonder if he was clear on what would have constituted a successful outcome for this project. He may not have, I speculate, recognize this in the moment, and perhaps did not ask questions to help clarify these unspoken concerns. Consequentially, there might have been too much ambiguity which typically results in “padding estimates. The more unknowns, the more fear of what is unknown, leading to higher estimates.

    I appreciate the post as it reminds me as one who makes requests and also fulfills them to be clear in what I am asking and to make sure I understand what is being asked of from me.

    • Hi Rick.

      I think it would have crushed him if I had asked for a promise or commitment. People really get blown away when we use words that immediately trigger them to some level of severity that they don’t use in their normal language.

      To say that an estimate is a promise or a commitment is philosophical. They don’t have to see it that way… and if I start using terms like promise or commitment that they think to mean something else they could be crushed in the very way that leads people to pad their estimates… just as Frede said above.

      What I am really looking into is what it is inside of people that creates the fear of committing in the first place. Even if we say an estimate is a guess, as soon as one person organizes their thinking around it getting done in that time frame, there is a possibility for unmet expectations.

      When I think of that fear, managers and developers may be co-conspirators in creating and sustaining it. Where I was looking to decide whether to chase the opportunity, the developer was skeptical about how managers have used his estimates in the past.

      As we got toward the end of our conversation, he actually said, “Well, you are different than most managers!” – in suggesting that I wasn’t going to crush him if he missed his estimate. Of course, my response was, “I intend to be, so thanks.”

      But that doesn’t mean that if one manager has a different outlook on building trust, his staff can shake a history of mistrust and distrust overnight.


      • Hi, Ken —

        While I agree that changing vocabularies relative to someone’s norm can induce stress, it can be equally stressful when all involved know how much variation exists in the industry for a term like “estimate.” Does your developer know what you mean? Do you know the developer’s background to know how he interprets it? If “promise” or “commitment” induce stress, but that’s really what you mean anyway, it’s probably better to have that issue out in the open than residing in the subtext.

        Personally, when I can’t rely on empirical methods for an estimate, I prefer to have the conversation in probabilities and risks. That’s really what you’re doing when you translate the negotiation into a confidence level. It’s also a less threatening formulation than promises and commitments for those who aren’t comfortable with that language. Go back and read Goldratt’s analysis of the correlation between the completion probability curve and padding. I’ve always found that very insightful and a good tool to clarify what we really mean by “estimate.” Ask questions like, “What is the likelihood of completion in 5 days?” and you’ll get much different answers without the subtext of the negotiation.

        • Thanks Steve. Now that you mention it, I didn’t use the term “estimate”, “promise” or “commitment” in the conversation at all. As I mentioned elsewhere, we don’t formally estimate very often under our kanban structure, and very few things have the same time constraints as this one. Finding better language when something is clearly not a common practice is good counsel.

          Your other suggestion makes me think of ways I could have put some more context around my request. It is not so much that we did not all have the same details, but that doesn’t mean the details carried the same meaning for both of us.

          So it appears to me that one answer to my question about ways to work with a cultural norm isn’t just in the setting up of the safe environment, but in a way being sensitive to the strong possibility it is there and moving into these conversations “from the side” with smarter language.

        • Ken, what was the risk-reward of attempting the project without an estimate? What would have been the cost of failure?

          If the cost of failure, or five days lost work, is relatively low for the possible value, why not take the bet?

          Perhaps these conversations should be less about exchanging time for value and betting a chance will pay off.

          I’ve worked with some amazing talent and trusted few of their estimates, but everyone of them is a horse I would bet on… and did. As a manager it was my job to take the risk, make the bets, and build or lose capital, trust, with my clients.

          It’s all about risk. Even the value of a promise is colored by our estimate of the risk of someone being able to deliver on the promise. It’s sometimes called counter-party risk.

          I’ll have to think more about it. As usual, reading your posts is worth the risk. It’s a pretty safe bet they’ll be interesting.

          • Hi Tom. Thanks for your questions and comments. They are also worth the risk of answering.

            As you know, but probably most other readers don’t, our company emerged from Chapter 11 literally a week ago. We have such a great backlog of reports, enhancements, automation and controls coming out of the restructuring that many of our strategic deadlines are measured in days or weeks, and not months. Many of the observations related to estimates are (reasonably in my assessment) coming from perspectives of agile teams, steady release management and project-like focus.

            There are many situations in our lives right now that are more agile than agile… there is no single sprint or release in this ultimately adaptive situation, so we have gone to kanban for work management in streams, and the notions of flow and cycle time are everything to us right now. (Of course, you and I spoke in the summer about how suitable I thought your project at the time might be for a kanban system as well.)

            So where our development capacity is the bottleneck that regulates flow of business value, not only from IT, but for many of our operational restructuring activities, losing five days of capacity is a tremendous loss… especially for an “opportunity”. If the situation were a threat or a duty we were required to fulfill, then we might not have even had the estimate conversation.

            Of course, having a private equity owner now, who is new to us (and us to them), also creates instability in understanding and communicating priorities… which I anticipate will change over time. But until then, we are something like a manufacturing plant that can’t afford to get stuck with a lot of Work-in-Process when the model year for our products changes.

            In my first six weeks here as the date of the filing got closer, I was increasingly drawn to kanban… and it has really had a huge impact – we are producing more valuable changes faster with 1/4 of the people the company had 18 months ago. And we really don’t estimate as much a triage in setting priorities – threats, obligations and then opportunities. So when the business case for this opportunity had a deadline, the question became whether or not to do it.

            And though I can say I don’t lose sleep over passing up the opportunity, I do have to work with my team so they know it is nowhere near as important to pass up an opportunity as it is to ignore a threat or an obligation.

          • Oh, and with respect to betting… I don’t play the odds of winning in a Random Walk. As you mentioned, the knowledge and skill of my team keeps us from the Random Walk, so to me it isn’t about betting anymore. There is always a risk of failure, but when so many positive outcomes we could produce are waiting in the prioritized queue, there is much less need to gamble on something speculative. In my continuous improvement world, it is more like passive investing… our skill and talent can help the organization grow, and we will take opportunities when we can… but we will always keep moving forward.

            I suppose that would also be different if we weren’t post-emergence with an awesome backlog of other valuable things to do.

  3. Interesting article.
    Have you ever thought about reducing the scope to meet the timeline? i know this is really the product manager’s job but it sounds like you have that role as well. In this case you can work with the developer to form a decision based off quality scope and good timeline.

    • Thanks, Geoffrey. For standard work items, obligated requirements and even optional work, I think that is sound advice.

      The request for this estimate was based on whether or not to capitalize on an opportunity… which will not come back around for a little while. If we could not hit the window, it would only have cycled my team and consumed their capacity on something we couldn’t ship – work-in-process from a lean perspective.

      I decided to defer because the estimate would not have worked into the time frame and the subsequent negotiation about it did not give me confidence that I wouldn’t be signing my guys up for an impossible task.

      As I mentioned to Frede, our current approach and use of kanban is driven by cycle times and business priorities more than individually estimated work items.

      If we thought it would have fit into the time, I would have considered flowing this opportunity on an Expedite lane, but if the estimate says it isn’t possible, I am going to redirect my team toward what is.


  4. Thanks for this post, Ken. I’ve actually shared it with some of my team members as we’ve had some discussions around our team concerning this very subject.

    One of the things that really drives me crazy is this notion that if an estimate isn’t complete, we’ll just reduce the estimated points to what is remaining and note “what is left to do”. This seems so counter-intuitive to the principle of agile. The idea, as you noted, is to think of the estimate as a commitment not on what we are going to work on, but on what we are going to deliver.

    In reviewing our card board last week, we saw a card which has had its original estimate reduced four different times now. This means this card not only didn’t meet the promised delivery, but it has done so spanning four different iterations now while other things continue to move through the pipeline. It just feels dirty!

    I really like your consistent message comparing estimate to trust. The customer is the focus in agile development, and we gain their buy-in through delivering continued value. If the task cannot be completed across several iterations like the previous example, I would suggest that there is either a flaw in the gauge we are using to estimate or we need to become better at breaking down user stories into more tangible deliverables.

    Thanks. Extremely insightful post indeed.

    • You bet, Michael.

      In a traditional agile sense (if we can say that), I would look at the situation you described and consider splitting the cards that are too big. Another option is to create a new card for what is leftover and call the old one “done enough”. In your current situation you could have just started with a single card titled “Write the system” and then cross everything out with each refinement of your understanding.

      I would also consider what cultural norms are in place that aren’t making people feel really uncomfortable living with broken windows and a messy floor.

      (That is what it is like to me to have a visible card wall that stares at you every day saying you are not honest with yourself or your teammates. It actually erodes trust with each passing day, and it makes people pay lip service to trust and to agile practices. I don’t know the situation and I am not judgmental about it… but good leadership can really help people get through tough times like that.)

      Consistency regarding trust is really important. Breaking trust is super-easy… and you break it most often by commitments implied by your words and actions, whether or not you know that you made them.


  5. I’m not going to try to reiterate what’s already been said before:

    It’s not a promise, it’s a guess

    • Yagiz,

      Thanks for not reiterating and thanks for the link. In that post, David calls out “When you call an estimate a promise, you bind your worth as a worker to it”. I respect that position and I fully understand it.

      My teammates do not define their worth as workers, but business professionals. No one who thinks their worth is in the hours of labor they give away to their jobs, and not to the brilliant, creative and highly valuable outcomes they produce, will ever want to make a promise to anybody.

      And that is OK. If you don’t make a promise, nobody has to accept promises from you. If, on the other hand, you make promises and you deliver on them, your value and trustworthiness increases.

      One other consideration is whether it is management who “requires” you to think of your estimates as a promise, or whether as a matter of professional integrity you have chosen to think that way.

      My coworker gave an estimate, and it didn’t fit our timeline, so I moved on. That is the consequence, and it is not good or bad. He was not good or bad… we just won’t be doing that piece of work in the near future.


  6. This post got a great comment on a closed (private) LinkedIn group that we would love to credit to its author, but that runs contrary to the comment guidelines of this site. To paraphrase, it started with “People do not just pad estimates for fun, one needs to look at the underlying reasons for padded estimates.”

    There were a couple good examples that are consistent with other postings… and then later on: “Does the estimator understand the importance of the effort? Giving a high estimate is a somehwat subtle means to cancel an effort.”

    • Sometimes my focusing on trust, responsibility, promises and commitments makes me feel like I was born under a rock or something… but I had honestly never considered that someone would inflate an estimate to kill an effort. I still have trouble thinking about that one, even though I can see how the mechanics would work.

      I figured this was a consideration worth sharing, though I do not think it was the case in this situation. It makes me think about what personal ethics I could establish and what positive means of influence I could prepare to help avoid what seems to me like “opportunity sabotage”.

  7. Ken,

    That’s a very normal practice we see in IT industry. Major reason is that scope defined while creating initial estimate almost always go for a toss and the final product defines much different scope than they have estimated in initial phase.

    The best practice is to take some time and break the project in various detailed tasks which can be defined technically. Once you’ve done that developers find it easier to sync with number of hours.

    I do have a couple of years working with some smart developers and it’s always fun finding ways of getting best performance out of them.

    • Thanks, Gaurav. I also see this as a normal practice, though since posting this I also recall (through the observations of other commenters) times when I experienced the exact opposite – optimistic underestimating – I can personally confess to this… and when it has happened, my stance about “promises” means I accept long evenings and weekends working as a consequence of my promise. Still, I find it powerful to make promises and keep them. Accepting responsibility is the key… if you never make a promise, you can be as irresponsible as you want.

      None of that is directed at you or your comment. The thing is, when you are working with people you trust, especially when you have worked with them for a long time, promises come naturally and you can absorb the peaks and valleys. It sounds like you have similar experiences as well.

      Thanks again for your observations.


  8. Ken, Thank you for the thoughtful posting.

    From Steve’s comment, “changing vocabularies relative to someone’s norm” could indeed be stressful. However, it could also be inspiring when designed and spoken in a way intended to evoke “wonder”. I have focused on that aspect of working with language when dealing with various backgrounds, especially software engineers, software managers, and CTO/CIO leaders as in your position. In the instances that I have evoked the “… I don’t know what this means, but it sounds good!” the reaction was spoken in “wonder” – and of course underlying that, humility on their part for saying that.

    When I get this reaction, I go “Ah! This is the “notice”. This is the “pointer” to a new distinction that just showed up for them, it simply doesn’t have a name yet in their listening so they have nothing to hang on to. But something new did show up. This is the occurrence that I always take advantage of to start building more [new] background with the purpose of helping that person really “get” what I’m communicating. I suspect you already have experienced that in one form or another. And of course, there are the other typical reactions that range from being offended to reacting like you had hurt their feelings, as you describe in your posting.

    The central concern in your posting, as I understood it, is that for you to “capitalize on an opportunity” you need estimates that fit your conditions, constraints, and time horizon, otherwise, you can’t use them – regardless of what definitions and technical methodology was used to produce them. This is so meaningful for changing the cultural norms that you write about. Being able to pull your readers and people around you into your intended meanings and purposes has a high likelihood of producing drastic positive results.

    I work with customers on “practice reconfiguration” – mostly linguistic work. What I have recurrently and consistently observed that ordinary software developers live in the conceit of their talent; project managers in the linearity of their plans; and people in general like to endlessly debate definitions … which completely misses any opportunity of producing innovations, accomplishments and trustworthiness.

    I always ask in early conversations with leaders and executives:

    How different would your environment be if your developers understood your business concerns and held them as their own, and knew to deliver on their commitments – compared to sole reliance on the usual and typical work [guess]timation practice?

    How different would your environment be if your technology team leads competed with their “best offers” for a project, backed by their commitments?

    How different would your environment be if your technology group made an “offer” that actually beat the very conditions for success that you have set for a project – with whatever magic they have up their sleeves, and of course backed with real trustworthiness and previous accomplishments?

    Great posting! Thanks.

    Ernest Stambouly

    • Ernest, thank you for your observations. Please excuse that I changed your formatting slightly, but I wanted each of them to come through – I did not alter your words or make any other edits than that.

      You probably noticed that Steve is one of those guys I grant authority to show me a simple and powerful path that I could not find before. He has been a great teammate and friend for a while, especially when I do something silly or naïve.

      Meanwhile, your writing about language is at the core of my thinking through this situation. It would be nothing for me to move on, tell myself a happy story and accept a convenient interpretation of managers and subordinates and their various interpretations of risk.

      That none of us can fully share the whole picture of risk or the same interpretation of the situation is where linguistics come in, and many of the comments here and on LinkedIn have given me plenty of alternative tools for thinking about this situation.

      Your three closing questions are great – they suggest outcomes that are valuable to me. Establishing the foundations for language about offers, commitments and even the notion of “taking care” is a journey that can produce great returns.

      I have been burned in the past by having a shallow interpretation of “holding others’ concerns as our own”, however. Whereas we can grant authority to others to produce outcomes on our behalf, we remain responsible and accountable for the outcomes if we also want to claim the accomplishments. My team and I can speak of my concerns… but as I suspect you accept, they are mine first… delegation and followership don’t shift responsibility.

      Kind regards,

Leave a Reply