Skip to main content

#NoEstimates Year in Review

The hashtag #NoEstimates was originated by Woody Zuill for "exploring alternatives to estimates [of time, effort, cost] for making decisions in software development." What began as a conversation between a few people (Woody, Neil Killick, and Vasco Duarte) grew into a much larger discussion. As the year 2015 is now over, let's take a look back at what we learned from the discussion.

A lot of different people have participated, each bringing their own unique views and experiences. There is no single "#NoEstimates view"; what one person says doesn't represent the rest of the group. Some argue that estimates should be used more sparingly, others never at all, and yet others that suggest that only under certain circumstances.

Despite the differences, there seems to be consensus on the following key points:
  • Software project often fail. Perhaps the use (or misuse) of estimates play a role in this.
  • Estimates are often turned into commitments. This mechanism is used to put additional pressure on developers, often with questionable results.
  • Compromising product quality to meet scope and date commitments is usually a bad idea.
  • Making small bets is better than big bets.
  • Story slicing is a great way break down user stories/requirements.
There might be a few others that I've missed, so feel free to comment if you think of any. The important thing is that a lot of great discussions have occurred, and new ideas have been shared. I'm sure as 2016 progresses the discussion will continue to evolve and more great ideas will emerge. Onward and upward!

Comments

Post a Comment

Popular posts from this blog

Value and Quality over Schedules

According to a study by CEB Research, 70% of software projects are delivered on time, but only on 38% meet stakeholder's expectations. In most cases the people that use your software will not even be aware of internal project deadlines. Case in point, think of all of the software the you use everyday. You are rarely aware of what the due date was. However, what you do notice is how well the software does it's job. It's it's of low quality, you'll very likely notice right away. Even if it appears to be of high quality, if it doesn't provide any major value to you, chances are you still stop using it. With that in mind, then why do many software projects today have a set scope and a hard due date? When building software for a customer, it's only natural for them to what to know what exactly they are going to get and what is will cost them. That is a very reasonable thing to want to know. Even when developing software internally, there are often similar expe
4 comments
Read more

Let's Get Moving With Software Development!

Recently I was reading a discussion on Twitter about software projects, and it reminded me of something. Many years ago I had a conversation with my dad about moving. After just having moved, he wasn't too pleased with the moving experience. He mentioned that there was essentially two models that movers operated under. The first was you paid a fixed price for the move. I don't remember the exact details, but the movers quoted a price most likely along the lines the square footage of the house, or some similar metric. The other model, was simply to pay the movers for their time. If it took them 20 hours to complete the move, you paid for those 20 hours. Now the catch was, as he described it, if you paid for a fixed price the movers didn't really put a lot of care into the move. They simply wanted to get the job done as quickly as possible. I seem to recall that if they broke something, they would reimburse you. However, that wasn't a pain free process. More importantl
5 comments
Read more

The Cost of Meetings

Meetings ... love them or hate them they are a part of everyday business life. I've had multiple bosses that detested meetings, saw them as a waste of time, and would dissuade us from having them. On the other end of the spectrum I've worked for organizations that had countless meeting, many that were of little relevance to me, and left little time in the day to accomplish my other duties. In this posting I aim to examine the cost and benefits of meetings, and also touch upon what it takes to have effective meetings. As someone that has worked as a software developer, team leader, and manager of developers over the years, I'd like to think that I've seen the good and bad side of meetings. Let's start first with the cost. Everyone would agree that a 1 hour meeting requires at least an hours worth of time for everyone that attends. Add to that the need to break ones focus from what they were doing, and regaining that focus after the meeting, you may even raise that
4 comments
Read more