Skip to main content

Relative complexity

Last post 04:49 am March 30, 2016 by Ian Mitchell
9 replies
Anonymous
03:31 am December 15, 2013

Hi all,

I wondering how your teams deals with User Points.
We based our User Points purely on complexity (relative complexity of course) not time as our Sprint is a timebox already.

We do this because of the following reasons:
- no expliciet exact time planning.
- much easier and faster to estimate.
- time can be a personal related factor.

I must say that the team is getting better and better but i cant help to think about the following points:

1) what about simple items that takes a long time. In theory the team can give this item a 1 but it takes 5 days. And perhaps there are items that are more complex but takes 2days.

2) do you change points during the Sprint? I don't mean all the time but only when the team did a totally wrong estimation?

Cheers,


04:55 am December 15, 2013

> what about simple items that takes a long time

That's the problem with estimating by complexity. Mundane tasks may not be complex, but they can absorb much of a Sprint. Why not estimate by effort instead?





Anonymous
08:00 am December 15, 2013


Posted By Ian Mitchell on 15 Dec 2013 04:55 AM
> what about simple items that takes a long time

That's the problem with estimating by complexity. Mundane tasks may not be complex, but they can absorb much of a Sprint. Why not estimate by effort instead?



There are 2 reasons which I can think of right now:

1) effort is a relative word. For a senior developer it may take 8hrs while for another less experience developer it can take up to 16hrs or more. The moment we start using effort (time) the estimation process takes a much longer time because they want to get more exact.

2) when the client figure out effort is equal to time, deadlines will be created and before you know it, were doing Scrum in a waterfall environment. I want to keep a strict line between "how long will it take" and "how complex is this gonna be"


03:14 am December 16, 2013

We do estimate by "effort" also. It is a way for us to estimate "everything" : dev effort ; test effort ; doc effort...
It is very common to have something easy to dev and difficult to test or the opposite.

The estimates don't nedd to be accurate, and we don't re-estimate after the sprint is over because we don't have the need to do that.


05:47 am December 16, 2013

> We do estimate by "effort" also. It is a way for us to estimate "everything" :
> dev effort ; test effort ; doc effort...
> It is very common to have something easy to dev and difficult to test or the opposite.

The work an agile team does is indeed varied, and some of it can be unusually demanding, even if it is not particularly time consuming. Effort doesn't really correlate to time.


Anonymous
05:57 am December 16, 2013


It is very common to have something easy to dev and difficult to test or the opposite.



So overall it would be a complex item no?



The estimates don't nedd to be accurate, and we don't re-estimate after the sprint is over because we don't have the need to do that.



We also never changed our estimate after the Sprint. What we do do is re-estimate (after the Sprint) if it's needed.




02:17 am December 19, 2013

Our teams based story points based on Effort instead of Complexity. :-)


02:13 pm March 29, 2016

I'm not sure complexity necessarily relates directly to time spent. There can be simple solutions to complex issues that are executed in a short period of time, and vice versa.

Whereas, effort seems to relate more directly to time spent in most cases. If capacity is a constant, a "large effort" takes more time than a small effort.

Are there better definitions of complexity or effort that would help me understand the best way to set Story Points?


03:52 pm March 29, 2016

Hi,

I like to come back to the original questions:




1) what about simple items that takes a long time. In theory the team can give this item a 1 but it takes 5 days. And perhaps there are items that are more complex but takes 2days.

2) do you change points during the Sprint? I don't mean all the time but only when the team did a totally wrong estimation?




No matter if you do your estimations by complexity or by effort. In the end it is just an estimation - which by definition - doesn't need to be correct. In my opinion there is no need to adapt an estimation after implementation.

I like to add the following: Up to my experience the teams get more precise in estimating over time. For me the most important thing about the estimation is to add insight about the increment (e.g. the discussion when playing "planning poker" or the movement of the cards when doing "magic estimation") - the number itself is less important.


04:49 am March 30, 2016

The purpose of estimation is to help a team decide how much work it can take on in a Sprint. Strictly speaking, it is up to each team to decide how that assessment should be made. "Points" might therefore correlate to time, or effort, or to complexity or to a function of any of these things...or something else entirely.

I generally coach that an estimate may be a function of time, effort, and complexity. This is because a time-consuming activity is not necessarily hard work, a high-effort one is not necessarily slow, and a complex one is not necessarily ponderous or tough to do.

In short, the required pace of work can vary for each item, and estimates should take this into account during estimation in order to avoid underutilization or overload.


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.