Relative complexity
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,
> 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?
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"
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.
> 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.
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.
Our teams based story points based on Effort instead of Complexity. :-)
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?
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.
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.