3 ms·

if pressure is ramping up and quality down the sprints arent serving their purpose. One of the few defining characteristics of scrum is that the developers def

• crdoconnor 10y ago
  A few defining characteristics of scrum that lead to overly optimistic predictions: * The prediction is made in a meeting while your head is "out of the code". * The prediction is made in a group setting, rendering the decisions more easily subject to peer pressure and groupthink. * The prediction is made up to 2/4 weeks in advance of actually doing the work. * The prediction is made without risk of overshoot attached. Risk is critical metric which scrum conceals. And the main defining characteristic of scrum that leads to pressure, after all of that unwarranted optimism: * The prediction is designated as a commitment.
  • cechner 10y ago
    It sounds as though you objecting to being required to give any estimate at all.
    • wott 10y ago
      I don't know how you manage to read this. He seems to say he would like to be in a situation where he has the means to give good estimate but scrum forbids it and forces to give random and biased estimations.
      • cechner 10y ago
        can we infer that he would like to give his estimates: * while he is actually writing the code (so not up front) * not in a group setting but as an individual, so either one person estimating the whole thing or each person giving different estimates * (third point same as first, dont want to estimate up front) * must incorporate what is often called 'contingency' (which is actually what the whole point of measuring velocity is for!) * and the final point - he doesn't want to have to commit to it how can you _not_ read this into it?
        • Chris2048 10y ago
          Assume each person giving different estimates for their own work, but not up front - ongoing as code is written. How is that the same as not being "required to give any estimate at all"? > he doesn't want to have to commit to it why not? an estimate is an estimate, not a commitment. Committing to an estimate makes it a commitment, not an estimate. I might expect a dice roll to be 3.5, I'm not committing to the next roll being 3.5 - analysis should inform policy, in this case expectations informing stated commitments, but the two are not the same. Furthermore, this bullet point actually takes the quote out of context - He specifically doesn't want to commit to the estimate produced under the previous conditions, not that he won't commit to any estimate. The difference is choosing to commit to an estimate you have high confidence in, versus any estimate given automatically being a commitment (where estimates may be required on demand).
          • cechner 10y ago
            it is totally reasonable for stakeholders to want to track your progress through a project. If you have a good way of doing that then great, you should use that. Scrum people believe that scrum is the simplest way of measuring that. But at some stage you have to estimate the constituent parts of the project in order to get an idea of its size, and for those estimates to be useful in tracking your progress you have to do it in advance. I repeat however, if you dont need to do this then thats fantastic! Many of us do however, and some of us choose to use scrum to do that, and some of us have had a great deal of success with that. (edit: I worry that this sounds condescending. I am just trying to keep the tone friendly)
            • Chris2048 10y ago
              > for those estimates to be useful in tracking your progress you have to do it in advance In advance of what? The only constraint on a useful estimate is that is comes before the task is finished - it needn't be considered as credible at the earliest possible time. Also, your response doesn't really address my post..
              • 10y ago