Time vs Effort

Last post 12:47 pm April 22, 2014
by Ian Mitchell
2 replies
08:56 am April 22, 2014

My boss currently requires us to estimate stories based on time estimates. We follow Fibonacci's sequence, but each number in the sequence is linked to a time value. E.g.: 2 == "about half a day", 3 == "about a day", 5 == "1 to 2 days", and so on.

I read everywhere that story estimations must *not* rely on time estimates. Rather, estimates should be based on abstract metrics to quantify effort (e.g.: t-shirt sizes, dog breeds, fibo sequence, etc).

I would like to convince my boss that time-based estimates are bad, but I lack arguments. Since non-time based estimates seem to be recommended by everyone, there must exist tangible arguments in favor of these techniques.

So my question is, what could potentially happen (bad) if my boss keeps requiring us to estimate stories in time-bound points? What are arguments against time-based estimates, versus abstract metrics?

11:29 am April 22, 2014

what role does your boss have in the team? What does he need time estimates for?
Maybe he just needs time estimates to fill in some forms in order to fulfill company processes. Then you can just use your factor and calculate the numbers, knowing they are as fake as all other project's estimates.
In the long term it is of course necessary to convince the managers. Here is a nice summary:

12:47 pm April 22, 2014

> So my question is, what could potentially happen (bad) if my boss keeps requiring
> us to estimate stories in time-bound points?

A boss "requiring" a team to estimate in a particular way is a bigger problem than whether or not those estimates are time based. The first thing to do is to decouple the Scrum Team's choice of estimation method from external influence. Unless the boss is also a member of the Scrum Team, that means building self-organization which is independent of direction from line management. If your boss happens to be a member of the Scrum Team (i.e. if he performs one of the Scrum roles) then his influence must be that of a peer, and not one of authority.

Self-organizing teams usually find it easier to relatively size the work on a backlog. Time-based estimates are rarely accurate, especially in the case of larger items. The goal of estimation is to allow a Development Team to gauge how much work they can reasonably expect to take on in pursuit of a Sprint Goal, and to inform a Product Owner of how much work is likely to be remaining. Other stakeholders, including managers, should care about the incremental delivery of value, and not about a Scrum Team's method of sizing a backlog.