Observations on the #noestimates debate

There's a lot of talk in the agile community about #noestimates at the moment. There are the fervent pro-estimators, and the rabid anti-estimators battling it out for the hearts and minds of the agile community. I posted a comment on this blog post by Woody Zuill, but thought, because I rarely post here, that I would reproduce it here for y'all

 No estimates seems to me to be a great end goal for teams. Personally, I think estimation sessions serve a purpose far greater than just providing a number on a card for Proj Mgt purposes.
In young teams (Team form age, not team personnel) Estimation is a valuable activity in aligning understanding of the work. Estimation is as much about “This story is too big to work on” to, “Why do you think this is a five and I think it is a one?”.

Once teams have been together for a longer period of time, estimation starts to lose its value, sure. However, like most agile practice, it has it’s place and is a really valuable tool in my opinion. Much like the debate around ‘pairing’ as alluded to earlier, estimation should always be up for debate in retro’s etc. Once it’s time has passed, a team should feel comfortable stopping the practice.

I think the biggest danger of estimation is not from within the team, but rather, from outside. If estimation/commitment is used as some form of bat to beat the team with if they don’t deliver. Estimation is a team tool, a great way for a team to practice continuous improvement, and should be recognised as such.

Comments

Post a Comment

Popular posts from this blog

Using an agile storyboard as a scale of certainty

Image
As per my previous post, In my current team we have started using a 'Just in Time' (see how I feel weird about saying Kanban, not sure why yet) approach to doing various activities around development. Mostly this is around planning, but in that sense, we are also doing as much Just inTime as possible in giving an estimate. Scene setting We are a team that does 2 week sprints, but we also don't do a major release at the end of each sprint. We tend to wait for 5 sprints to pass before we do releases, there are a number of organisational reasons for that, but suffice to say, thats the way we do it around these parts. Our story wall (in ugly table form) The table below is a basic representation of our Story wall. As you can see, for the story wall, we deliberately do not just focus on the current 2 week sprint. We also have columns heading beyond the current sprint to encapsulate the entire release timeline (in this case the team have already completed two sprints so their are
Read more

A survey on release processes with organisations that 'sef-identify' as folowing agile practises.

Image
Earlier this year I ran a survey around ‘release processes’ specifically with companies that follow agile practices. I promised that I would publish the results and apologies for the delay, I have collated the responses below. Thanks to everyone that participated, really appreciate your time and energy. At iflix we're always looking to improve our release processes so it was really great to get so many good responses. We learnt we're not that far apart from our peers out there. We've got a lot to learn of course, some of that comes from hearing from others and some from the mistakes we make. The trick is to make your mistakes small ones and learn fast with minimal disruption to your customers. This survey was run at least 5 months ago, so it’s a snapshot in time.  Most places I have worked change their processes (inspect and adapt!). I've reproduced the responses in their entirety, so it is a bit of a long read. I’ve anonymised the responses somewhat, retaining
Read more

Mission Orders, 6 military principles that can work for agile teams

Yesterday, I was watching a documentary on the "Battle of the bulge" A famous battle in World war 2. The docu makers were investigating German tactics during the battle. Specifically, tactics which had worked so well early in the war, over extended periods of time, towards the end of the war, fell apart after 3-5 days. Early in the war, German officers had Mission Command, that is, Hitler and high command had high trust in their teams. As the war went on, and things started to go wrong, mission command was gradually eroded as trust fell (especially when his officers tried to kill him). Mission command basically means, set the goal, let the teams be responsible for how they are carried out. Training is centred around this, discipline and training carry you through the unexpected, as long as you know the end goal. Effectively, the German high command no longer trusted the lower ranks, and only gave them enough information, goals etc for the immediate goals and set them
Read more