So, “who needs to plan? “ or “what shirt size works for you?”

How often have you worked at a company, where development is managed using “Scrum”? At the same time, while “scrum” was going on the “developers cannot commit on hours” was a very often response when asking “so, how long will it take to build it”?

When coming to estimates, developers are notorious about being very bad at it…This is particularly so when it comes to very long projects. When you ask a developer “how much is done?” on a 2 year project, 2 months in, the answer is “80%”, asking the same question on the same project 20 months in, the answer is still “80%” — so, the real question is, how is this possible, and even more importandly, how do we solve this issue?

Scrum was designed to address this problem. By designing a process in which teams self-organize, self estimate (rather than be dictated to by an outside manager) and use an agile Sprint based approach things were supposed to improve.

Assuming that the reader is familiar with Scrum (if not, it is about time you learnt…) the fundamental idea of self-organization and self-planning is to empower team members to internally estimate effort on short-term (no longer than 4 weeks) sprints.

Effort estimation can be done using “t-shirt sizes” (S, M, L, XL), Fibonacci (1,1,2,3,5,8…) or (god forbid) using actual hours.

While some organizations use t-shirt sizes or other techniques, we are “actual hours” proponents, this is why:

Many claim that since “developers cannot estimate” they should use t-shirt sizes (which actually, to most normal people doesn’t mean anything, when applied to software) or any other system, as long as no one has to commit to concrete estimates. This way, it looks like estimation is actually happening, but, since you still don’t know when things will end, there is no real dead-line or “responsibility” the developers need to assume.

We believe that this is another way for reducing actual engineering capabilities and taking responsibility away from the “kids” (the developers).First, we do not think that developers are “kids” and we think that on small tasks, up to 1 or 2 days in size, developers can provide a pretty good estimate (definitely good enough to commit to).

So, when we start a development project, we demand the developers on the team to commit to actual hours (yes, actually commit, not a typo).

Many, refuse to do so, or, are very specific about “we cannot estimate” , yet, what we found out that after some “blood sweat and tears” a shift in behavior and state of mind happens:

behold the developer estimating hours of effort (silence in the audience)

Once developers actually start estimating actual hours, we found that, not only that they become better estimators, but, the product is actually delivered as expected, on time, on budget. I also suspect that those who become the best estimators also become better engineers as a derivative outcome.

It does take time to get to the point where estimates are effective and have a high level of accuracy, but, we also found that it takes 2–3 sprints to get to the point where the team finds its stride, estimating in hours is actually not an abomination and, developers are actually proud in their ability to commit and deliver on their commitment.

So, to summarize, we believe that developers can actually estimate, in small chunks, tasks that are no longer than 2 days and, they should be held responsible for those estimates. In fact managers should demand them to provide hour-based estimates, this will make them better engineers and your organization a better organization.

We feel that allowing developers to “estimate” without actually estimating (for example, using points or t-shirt sizes) is a management failure. We also know that accurate estimates are possible and driving hard to getting them leads to less team stress, better planning and delivery of great software products, on time, on budget.

Article by Jonathan Chashper, CEO and Founder of Product Savvy.