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

Achieving Flow: Part 1

One of the central tenets of agile software development is the ability to quickly respond to change.  Instead of planning for months or even years at a time, as was common before agile, many software teams plan in short 2-3 weeks iterations. While that's certainly an improvement, to a much lesser extent there are even more nimble teams that deliver daily. There are many things that impact a teams ability to deliver quickly. Technical debt, unclear business needs, and constant interruptions are a common few. However, by and far the largest one of them all is not widely recognized. It's all of the waste we have baked into our processes. Let's examine a typical scrum sprint. The product owner comes up with requirements in the form of user stories. During the sprint kickoff the requirements are reviewed with the team. While many questions are answered during this meeting, ultimately more questions will come up afterwards. If the product owner is not immediately available to...
Post a Comment
Read more

Our Experience With Mob Programming

I was first made aware of Mob Programming well over a year ago. While I've always felt that you can do great work in collaborative environments, I have to admit that at first I was somewhat skeptical of the idea. How could having the entire team work on one thing at a time be as productive as everyone working in parallel?  Having said that I considered myself open minded and am always willing to give something a chance. As mentioned previously, I've had great experiences working collaboratively in teams. In the past I worked on a large team making complex software, and our best work was produced after designing as a group with white boarding sessions and intensive debates about best approaches. I had also worked for a Credit Union, and worked hand in hand with the business to help come up with ideas on how to best utilize technology to solve their business challenges. Only by collaborating as partners were were able to come up with practical solutions that properly addressed...
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