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

The Retrospective From Hell

Over the last 17 years of my career I'd like to think that I've learned a lot. I've learned from positive role models, from experience of what works well, by studying my craft, and from my own trials and tribulations. However, I believe the lessons that I have learned that had the biggest impact is learning from failures. One such failure occurred at a previous employer. By telling the story of a past failure, we can reflect and see what can be learned from it. No names will be mentioned, no embellishment or poetic license will be will used. As a matter of fact, I will make every attempt to be objective and accurate as possible. The truth of the matter the story doesn't need it; it speaks for itself. Some time ago I worked for a company that, among other things, had a software product. There was a small team of software developers, and someone that acted as the manager of the team. I was brought on board, as a software engineer, to help with the software product as
Post a Comment
Read more

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

How to run your IS department

Over the course of being a software developer for the past 10 years, at 5 different employers, I've noticed a reoccurring problem at these organizations. The business leaders simply don't understand what IS does and the value that they can bring to the company. (The one exception being a software consulting company, where IS was their business.) Most organizations tend to see IS in a similar light as brick layers or plumbers. They are simply there to keep things working. Additionally they are there to build what other business leaders have envision. In this analogy the business leaders are the architects, coming up with the grand designs, while the software people are the construction workers, putting the pieces together. What the business often fails to realize is that role of IS is to help the business run more efficiently, increases company wide productivity, and most importantly be a strategic asset to the company. In all of my working experience, the software
Post a Comment
Read more