{"id":697,"date":"2021-07-05T15:13:30","date_gmt":"2021-07-05T13:13:30","guid":{"rendered":"http:\/\/robertkalweit.com\/en\/?p=697"},"modified":"2023-04-06T15:45:43","modified_gmt":"2023-04-06T13:45:43","slug":"how-to-not-get-burnt-an-abbreviated-story-about-agile-estimation","status":"publish","type":"post","link":"https:\/\/robertkalweit.com\/en\/2021\/07\/05\/how-to-not-get-burnt-an-abbreviated-story-about-agile-estimation\/","title":{"rendered":"How to (not) get burnt – An abbreviated story about Agile estimation"},"content":{"rendered":"\n

This is the abbreviated version of an equally named article that was published in Medium\u2019s biggest Scrum & Agile publication, \u201cSerious Scrum\u201d: “How to (not) get burnt” on Medium<\/a>. The German translation on this blog refers to the full version and thus is much longer than this summary.<\/p>\n\n\n\n

If you\u2019re all new to Agile Estimation, here\u2019s a primer<\/h3>\n\n\n\n

Agile teams want to remove wasteful conversations about subjective durations of tasks<\/a>, therefore we estimate in Story Points, which is literally \u201cthe number of (abstract) points<\/strong> we estimate a (user-) story<\/strong>\u201d.<\/p>\n\n\n\n

Teams agree on an abstract estimation of effort one small user story that has already been done in the past. From then on all other user stories shall be estimated in multiples of that story or sums of effort of previously estimated stories. The well established best practice starts with Fibonacci numbers<\/a>:<\/p>\n\n\n\n

0<\/td>1<\/td>2<\/td>3<\/td>5<\/td>8<\/td>13<\/td>20<\/td>40<\/td>100<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Agile Estimation uses the Fibonacci numbers to estimate effort relative to other tasks: \u201cI think this feature is as much effort as those two features combined.\u201d (thus it’s also called relative estimation<\/mark>).<\/p>\n\n\n\n

\"\"\/
By Jahobr – Own work, CC0, https:\/\/commons.wikimedia.org\/w\/index.php?curid=58460223<\/figcaption><\/figure>\n\n\n\n

Why it\u2019s a bad idea to take on big features<\/h3>\n\n\n\n

Inherent uncertainty of big features makes it unlikely to finish them within one Sprint. Let\u2019s say we have a team with a rolling average velocity of 25. This team finishes items worth 30 Story Points per Sprint. What do you think is more likely?<\/p>\n\n\n\n

    \n
  1. for the team to finish 6 user stories worth 5 Story Points each or<\/li>\n\n\n\n
  2. for the team to finish 1 user story worth 20 Story Points and another worth 8?<\/li>\n<\/ol>\n\n\n\n

    Of course it\u2019s option 1. The organizational effort clarifying the uncertainties of the bigger stories and the potential rework after spending time building the wrong thing are the biggest hurdles preventing big features from getting finished within one Sprint. Because of this, teams commit themselves to not take on features exceeding a certain size but to instead break them down first.<\/p>\n\n\n\n

    Teams estimating on a limited scale and why this is a problem<\/h3>\n\n\n\n

    Some teams had realized that they committed to doing things too big to handle in a Sprint. Now in order to improve, they had decided to \u201ccut\u201d their scale at 13. The pitfall they fell for was: Limiting the scale doesn\u2019t improve your breakdown. Limiting your scale only leads to relatively different estimates, leading to an actually worse result.<\/p>\n\n\n\n

    Here\u2019s a metaphor for why limiting your scale is a terrible idea:<\/p>\n\n\n\n

    Say we measure the temperature of water. 100\u00b0C is boiling hot, but already 60\u00b0C hurts pretty much. Let\u2019s say we change our scale for 40\u00b0C to be the maximum. Nice, right? Now we can\u2019t get burnt anymore! Wrong! What used to be labelled<\/em> 60\u00b0C is now labelled<\/em> 24\u00b0C. We just changed labels, but we didn\u2019t (and can\u2019t) change facts of nature: Obviously we still get burnt.<\/p>\n\n\n\n

    \"\"
    Different labeling of a scale doesn\u2019t change the effect of the measurements. Scribble by the author.<\/figcaption><\/figure>\n\n\n\n

    When asked to size any item in the Product Backlog at a scale of 1\u201313 Story Points, teams will most likely adjust to the reality of the new scale: Suddenly 13 becomes the absolute maximum, the boiling point. This in turn means: The later, lower priority, less well refined backlog items further down in the backlog will be estimated as this new maximum of: 13.<\/p>\n\n\n\n

    The main disadvantage is that relations are less visible<\/strong><\/h4>\n\n\n\n

    The smaller scale has a much lower factor (a different relation<\/em>) between the items on the scale:<\/p>\n\n\n\n

    0\u200a\u2014\u200a100: This sequence has an average of 19.2 and a median of 6.5. The relation between the maximum<\/strong> and the median value is a factor of 15.4<\/p>\n\n\n\n

    0\u200a\u2014\u200a13: This sequence has an average of 4.6 and a median of 3. The relation between the maximum<\/strong> and the median value is a factor of 4.3<\/p>\n\n\n\n

    Backlog items estimated at the maximum of the scale very often represent later, larger, multi-sprint efforts and should definitely be broken down as time goes by. In the early stages of a project however, I have very often seen a huge difference between the well-refined User Stories of the first Sprints and the items further down in the Backlog. The factor between those was far greater than 4.3. This is relevant in order to make clear how much uncertainty those items entail.<\/p>\n\n\n\n

    Cropping the scale is outright harmful, since it decreases both accuracy and clarity around items:<\/p>\n\n\n\n

    \"\"
    Visualization of (extrapolated) Fibonacci sequenced efforts at scale. Photoshopped by the author.<\/figcaption><\/figure>\n\n\n\n

    The fix is simple: Give them the full scale again (and ideally a set of Planning Poker cards)<\/h3>\n\n\n\n

    Part of the problem was that the aforementioned team did not have planning poker cards (or an Agile Coach<\/a> acting as Chief Handicraft Officer who simply crafts some playing cards). They estimated by show of hands.<\/p>\n\n\n\n

    By now there are apps like Scrum Time Planning Poker<\/a>, but back then I just wanted to get those teams some real, physical Planning Poker cards. Online I found several products which made the same mistake: Ranges until 21, sometimes lower. So teams run exactly into the above described trap.<\/p>\n\n\n\n

    Fortunately there\u2019s also positive examples: Agile Planning Poker Cards by Ulassa<\/a> – the full scale and a great design. (Not a sponsored link, I just like them.)<\/p>\n\n\n\n

    My team later (re-)estimated the backlog: The increased granularity with the full Fibonacci-scale led to more realistic effort-ratios between backlog items. This in turn made it easier to predict delivery times. Using the full scale finally sparked conversations about splitting user stories again. Proper agile estimation was (amongst others) what the team needed to get things done again.<\/p>\n\n\n\n

    \n\n\n\n

    Further reading:<\/p>\n\n\n\n