Back to Forum

Time vs Effort

Last post 12:47 pm April 22, 2014 by Ian Mitchell
2 replies
Simon-Pierre Gingras
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?

Ludwig Harsch
11:29 am April 22, 2014

Hi,
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:
http://scrumorakel.de/blog/index.php?/archives/48-Estimating-relative-s…

Ian Mitchell
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.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.