Estimating in Comparison to Past Experience

The simplest method of estimation is to compare the anticipated work to past experience. And we all have experience that we can use. The big question is how relevant is that experience. A secondary question is how clearly do we remember that experience.

We always have experience, of course. We weren’t born developing systems. We’ve tried things, and learned things, from childhood onwards along a path that’s lead us to today’s situation. In all the things we’ve done, there’s something that we can compare with the work we’re facing.

What’s different about our previous experience from this? Maybe we did a development project last year, but this one seems more complicated. Or that one used a familiar technology stack but this one is based on new technology that none of us have used before. It’s still relevant experience. We’ll have to adjust our expectations to account for the differences, of course.

And there are always differences. Even if we were doing the same project a second time, we would have an advantage due to the learning we gained while doing it the first time. We can rarely model the current work with past experience on a one-to-one basis.

If this project seems more complicated, how much more? Is it twice as complicated, or ten times? We can make a rough multiplicative adjustment to our past results to approximate our expected results. If we need to learn a new technology, then how long will it take us to come up to speed? That’s an additive component to our estimation model. If last year’s project took us 6 months and it’ll take us 2 months to learn the technology, then 8 months might be a reasonable estimate for this work. Or, since we’ll have much less experience in the new technology, perhaps there’s a multiplicative adjustment, also, to account for the friction of working in unfamiliar territory.

The further our reference experience is from the upcoming work, the more we’ll have to adjust that model to predict the future. And the more we have to adjust our model, the more error is likely to leak into it. How do we know how much to adjust? That, too, is an estimate.

We make things harder on ourselves when we make unnecessary changes in the way we work. Often people dissolve the team at the end of each project and build a new one for the next project. One of the big benefits of keeping durable teams together and bringing the work to the team is having a track record for the team and how it works together.

We also benefit from working on one thing at a time. That makes it easier to track how much effort has actually gone into a project. When we multi-task, working on a major project but also being pulled off onto unplanned work that pops up, we have a harder time figuring what it took for that major project. Rarely do we keep accurate notes on how much we worked on one project vs other work. In fact, that’s quite hard to do in knowledge work like software development. How do we keep track of what problem we’re mulling over from hour to hour? And when we pay more attention to timekeeping, it distracts us from the problem solving and compounds the problem.

So, while estimating future work based on past experience is simple, it’s still not always easy. We can make it easier by how we arrange the work and how we approach it. I think there’s advantage in doing so, not only in easier estimation but in being more productive at accomplishing our projects, too.

2 Comments

Categories: Customer Collaboration

Tags:

2 Replies to “Estimating in Comparison to Past Experience”

  1. Hi George,
    I like that you end by saying “while estimating future work based on past experience is simple, it’s still not always easy”. I have seen that teams struggle with the accuracy of estimates, especially when contracts and formal commitment supersede trust, customer collaboration, and openness to experimentation… it is not easy for many to accept estimates for what they are – just estimates! Sometimes teams waste a tremendous amount of time discussing how to estimate with more accuracy. However, when trust is established, teams evolve. They might move away from planning poker with story points, to faster methods like t-shirt sizing and bulk estimates, or embrace #noestimates. Some also move from Scrum to Kanban and start slicing projects & stories really thin. That boosts throughput and team morale, bolstering trust even further.
    Thanks,
    Rahul

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.