The thinking here was that work that reaches a cycle time that is higher than 85% of the other work we completed is probably worth some extra attention. Is the person working on it stuck? Is the problem so complex that it might be useful to sit down and have a look at it together?
We all felt it was a good motivator to work together on a regular basis. Or at least step up the amount of communication around that unit of work.
My intuition would be: our "forecasting" solution is never going to be 100% right. Here's an example where it's completely wrong, scrap the "forecast" and get the work done. Don't sleep in the office overnight, don't throw more developers at it; acknowledge no forecasting system ever will get creative work predictions/forecasting correct.
One difference I see is that there is no consideration of the size or complexity of a "story" or unit of work. Scrum and Agile dictate that you spend tons of time and effort assigning points and shuffling points around to measure your velocity, etc. etc. This post seems to say, forget about points? As long as these stories represent a finite amount of work, the size of that work doesn't matter when forecasting how many more chunks of work will get done in the future.
Unfortunately some companies insist in using mam hours for estimations instead of story points then you end up into massaging hours into a virtual unit relating to story point to adequately compensate for the fact that not all developers hours are equal.
