{"id":14712,"date":"2015-10-19T08:00:51","date_gmt":"2015-10-19T12:00:51","guid":{"rendered":"https:\/\/simpleprogrammer.com\/?p=14712"},"modified":"2018-04-12T22:25:59","modified_gmt":"2018-04-13T02:25:59","slug":"the-noestimates-movement","status":"publish","type":"post","link":"https:\/\/simpleprogrammer.com\/the-noestimates-movement\/","title":{"rendered":"The NoEstimates Movement"},"content":{"rendered":"

I started out my career as a programmer and consultant to build e-commerce sites. Effort estimates<\/a> have always been around me while developing software. I have made effort estimates myself, and I have also asked other people to do it, then used them in all sorts of plans.\\n\\nAt the beginning of my career, I was absolutely crappy at making effort estimates. I once estimated a project that, in the end, took ten times longer than first expected. Later on, I gathered some knowledge and became better at it, but I have never liked to do effort estimates, and I think I share that sentiment with many others within the software development industry.\\n\\nWhen doing effort estimates, there is a certain feeling of unease; you can\u2019t predict the future, and you will be held accountable when more time is spent than was originally estimated. Is there another method we can use besides making effort estimates?\\n\\n<\/p>\n

History<\/h2>\n

\\n\\n\"SealingThrough Twitter, the three initiators of the NoEstimates movement met for the first time in October 2012. They were Woody Zuill<\/a> (an American software veteran),\u00a0Vasco Duarte<\/a> (a European author and agile practitioner), and Neil Killick<\/a> (an Australian agile practitioner). By reading each other\u2019s blog posts and continuing the discussion using the hashtag #NoEstimates on Twitter, they soon spread the word to others and the movement got started.\\n\\nAll of them were questioning the \u201dde facto\u201d use of estimates in managing software development, but they had different ideas about the core problems of using estimates, and therefore different approaches to the solution. If you watch the ongoing #NoEstimates debate today, it can be quite vivid. In later days, Ron Jeffries<\/a> and Kent Beck<\/a> (two of the authors behind the Agile Manifesto) joined the discussion and shared their thoughts.\\n\\n<\/p>\n

Three groups<\/h2>\n

\\n\\nEven if exploring still takes place regarding NoEstimates, I have tried to sort the positions into three groups:\\n\\n<\/p>\n

    \\n <\/p>\n
  1. Continuous delivery<\/li>\n

    \\n <\/p>\n

  2. Forecast\/projection driven<\/li>\n

    \\n <\/p>\n

  3. Estimation improvement<\/li>\n

    \\n<\/ol>\n

    \\n\\nThe first position, continuous delivery<\/b>, takes on a highly agile path by finding the thing that delivers the most customer value. When the most valuable function\/feature\/story is found, that, and only that, is implemented and delivered to the customer. The claim is that only when you have done and delivered the most important thing can you go on and find out what the second most important thing is, deliver that, and so on. If waterfall<\/a> is on one side of the spectrum, where everything is planned upfront, this is the most agile approach at the other end.\\n\\nBy regularly measuring the throughput of the team, like completed tasks per week, you can use that data to forecast and make projections<\/b> for the future. As W. Edward Deming stated, your process needs to be in statistical control (stable), i.e., only common causes of variations can be present. This, for example, is achievable for teams that stay together over a longer period of time and are working on the same product.\\n\\nThe last group I simply call estimation improvement<\/b>. Those people want to find ways to make estimates more accurate, and therefore more useful, for upfront planning. I see this as an attempt to stick with the waterfall method, and represents the least agile approach.\\n\\nMy experience is that project forecasts are needed, so I sympathize with the second group.\\n\\n<\/p>\n

    Planning a project before it starts<\/h2>\n

    \\n\\n\"Coworking\"If you are continuously measuring the capacity of your team, you can do project planning without effort estimation. You can use the following steps:\\n\\n<\/p>\n

      \\n <\/p>\n
    1. Measure capacity<\/b> – Count completed tasks per week for the team.<\/li>\n

      \\n <\/p>\n

    2. Analyze collected data<\/b> \u2013 Analyze your collected data to be able to use it.<\/li>\n

      \\n <\/p>\n

    3. Calculate metrics<\/b> \u2013 Calculate the metrics to be used for forecasting.<\/li>\n

      \\n <\/p>\n

    4. Time plan<\/b> \u2013 Check the times from the time plan, since time is usually a delimiting factor in a project (when the project shall be finished).<\/li>\n

      \\n <\/p>\n

    5. Forecast<\/b> \u2013 Make a forecast using the calculated metrics and the given time constraint.<\/li>\n

      \\n <\/p>\n

    6. Assumptions<\/b> \u2013 Fulfill assumptions so you\u2019ll be able to plan using this method.<\/li>\n

      \\n <\/p>\n

    7. Similarities<\/b> \u2013 Use the forecast and compare with other known references.<\/li>\n

      \\n <\/p>\n

    8. Think<\/b> \u2013 Given the gathered knowledge, think and judge if the project is feasible; if not, take proper actions.<\/li>\n

      \\n<\/ol>\n

      \\n\\nWith these eight steps, you don\u2019t need to spend valuable time doing effort estimates.\\n\\n<\/p>\n

      How It\u2019s Done<\/h2>\n

      \\n\\n<\/p>\n

      1. Measure capacity (completed tasks per week)<\/h3>\n

      \\n\\nTo measure the capacity, every Friday the team leader counts all the stickies that are in the \u201dDone\u201d column on the Scrum\/Kanban board (representing completed tasks) and writes the total sum on the board. This is repeated every Friday. Each sticky corresponds in our board to a sub-task of a story\/feature or a bug fix. Hence, the measuring is done on the lowest level of work that we track. The data is also plotted in a graph.\\n\\n<\/p>\n

      2. Analyze<\/h3>\n

      \\n\\nTo be able to use the collected data for further planning, it has to be analyzed. In other words, we must understand and be able to explain the \u201cpeaks and valleys\u201d. Likely, the capacity (throughput of completed tasks) is oscillating around an average\/median value, with a few tops and bottoms. If the data represents a stable system, we can make predictions for the future.\\n\\n<\/p>\n

      3. Calculate metrics<\/h3>\n

      \\n\\nTo be able to forecast, the following calculations must be made on the collected data using a spreadsheet program:\\n\\n<\/p>\n