Agile Tuning: Do Agile teams evaluate actual Story Points after each Sprint?

The goal is to leverage both priori vs. posteriori knowledge to make educated estimation.

Agile is not just the methodology to manage a software project, but a principle or even philosophy to run a business. Besides twelve Agile principles, what are those mechanisms which can well tune Agile effectiveness and improve success rate. For examples, what’s the priori vs. posteriori knowledge, should Agile team evaluate actual story point after each Sprint?

The priori vs. posteriori knowledge: The terms a priori ("from the earlier") and a posteriori ("from the later") are used in philosophy  (epistemology) to distinguish two types of knowledge, justification, or argument. A priori knowledge or justification is independent of experience. Estimates based on priori knowledge ignores completed stories. Estimates based on posteriori knowledge uses experience gained from completed stories. Any estimation is a model, and as such is neither good nor bad, but more or less useful at the time it was established. Say, a priori estimates are useful for two important ingredients of any agile process: 
1) unearthing hidden assumptions (when estimates diverge) 
2) finding out whether an item fits in the next iteration (aka velocity) 

Start with priori knowledge, and use posteriori knowledge to make educated estimates: Starts with priori knowledge based estimates from development teams, once teams complete a few stories, they have posteriori knowledge to make educated estimates. Any estimation is based on some knowledge about requests, and some time allocated for that estimate; any estimation has a known (and/or unknown) degree of incertitude (strongly depended on the first aspect). In many cases, the team have a-priori knowledge of the requirements, and (when using user stories), a set of examples of what you’ve already classed in the chosen 'buckets' of size. You look at what is in each bucket, and decide whether the story you're considering is more akin to the sizes in one bucket or another. Some of the stories in any bucket might already have been built, so you know, for those, which turned out smaller than expected, which turned out larger. This might help you judge the size of the one you had under consideration better, but you still need to decide which bucket you think it belongs in. Perhaps you have more knowledge, but you have no posteriori knowledge for this particular story. 

Retrospectives are a good time to evaluate actual story points for all stories in the Sprint. This would be effective in improving estimates in planning the next sprint. Teams should identify any bugs traced to completed stories and determine if the bugs were related to under estimating the story points. Both quality and planning would be improved. So, in the retrospective, you may delve into what went wrong and what lessons are to be learned. If you have any significant new knowledge that could influence estimation or the degree of incertitude is too high, then probably you need to re-estimate. 

The results of sprint must be analyzed and must be registered in the team experience. Story points are based on analogies and past experience and retrospective are moments when this experience is capitalized. Anyway, you should be careful how the fresh experience will be used in order to not be the victims of a "cognitive bias". The last sprint is more important than some past experiences (sprints) only if you have found direct related information need to be "injected" in some re-estimation. The goal is to leverage both priori vs. posteriori knowledge to make educated estimation.

Estimation is not the fact, just like this quote articulated "..but outside of maths all knowledge is fuzzy to some degree." The Agile principle underlying such technique is to make continuous improvement by applying the knowledge and experience being learned, but always be alert with the “cognitive bias,” and make the estimation model more useful than not.

Posted in: Agile