Forums

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. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

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.

Relative complexity
Last Post 30 Mar 2016 03:49 AM by Ian Mitchell. 9 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Pablo Rossi
Basic Member
Basic Member
Posts:170
Pablo Rossi

--
15 Dec 2013 02:31 AM
    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,
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1493
    Ian Mitchell

    --
    15 Dec 2013 03: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?




    Pablo Rossi
    Basic Member
    Basic Member
    Posts:170
    Pablo Rossi

    --
    15 Dec 2013 07:00 AM

    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"
    Olivier Ledru
    Basic Member
    Basic Member
    Posts:219
    Olivier Ledru

    --
    16 Dec 2013 02:14 AM
    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.
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1493
    Ian Mitchell

    --
    16 Dec 2013 04:47 AM
    > 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.
    Pablo Rossi
    Basic Member
    Basic Member
    Posts:170
    Pablo Rossi

    --
    16 Dec 2013 04:57 AM

    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.



    Joshua Partogi
    Basic Member
    Basic Member
    Posts:109
    Joshua Partogi

    --
    19 Dec 2013 01:17 AM
    Our teams based story points based on Effort instead of Complexity. :-)
    Eric Strodthoff
    New Member
    New Member
    Posts:1
    Eric Strodthoff

    --
    29 Mar 2016 01:13 PM
    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?
    Joerg Karlinger
    New Member
    New Member
    Posts:17
    Joerg Karlinger

    --
    29 Mar 2016 02:52 PM
    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.
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1493
    Ian Mitchell

    --
    30 Mar 2016 03:49 AM
    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.
    You are not authorized to post a reply.


    Feedback