- 1: 1
- TFB: Too Fucking Big
- NFC: No Fucking Clue
Despite the fact this could initially looks like a joke, it's actually a serious way to handle too large user stories and, from my point of view, it's very close to what has been suggested by other agile coaches like Neil Killick (My Slicing Heuristic Concept Explained), especially popular within #NoEstimates practioners.
The idea, at least at high level, is very simple: slice down your tasks until they are all more or less of the same size (1 story point), then your final estimation is just a matter of summing the total number of stories. Of course, it's easier said than done: too many misunderstand the NoEstimate practice, dismissing it as just a way to avoid the "hard work", but in reality the slicing activity forces a very accurate analysis of requirements, to be able to slim them down to a common size. The easy part is the final sum, but that's not the point.
In my opinion this method suggests that, when somebody says a user story is 5, 8 or 13 points in size, this implies a good amount of delusion, because in reality going beyond a 1, 2 or 3 size is so close to pure guessing that it is usually a waste of time. Using only a single size (one) it's even more effective, because forces a serious decomposition of tasks: if you can't achieve this level of decomposition then you should acknowledge that your requirements are not clear enough yet: drastic, but effective.
A practical approach to this kind of user stories slicing could be Gojko Adzic's hamburger method, when adding the constraint that each task composing the hamburger must be of size 1.
Many years ago I did something vaguely similar in a project: I decided that every user story had to fit into a week and every Friday was release / demo day. Not exactly continuous delivery, but I think it was even before the term "agile" was invented...
The idea, at least at high level, is very simple: slice down your tasks until they are all more or less of the same size (1 story point), then your final estimation is just a matter of summing the total number of stories. Of course, it's easier said than done: too many misunderstand the NoEstimate practice, dismissing it as just a way to avoid the "hard work", but in reality the slicing activity forces a very accurate analysis of requirements, to be able to slim them down to a common size. The easy part is the final sum, but that's not the point.
In my opinion this method suggests that, when somebody says a user story is 5, 8 or 13 points in size, this implies a good amount of delusion, because in reality going beyond a 1, 2 or 3 size is so close to pure guessing that it is usually a waste of time. Using only a single size (one) it's even more effective, because forces a serious decomposition of tasks: if you can't achieve this level of decomposition then you should acknowledge that your requirements are not clear enough yet: drastic, but effective.
A practical approach to this kind of user stories slicing could be Gojko Adzic's hamburger method, when adding the constraint that each task composing the hamburger must be of size 1.
Many years ago I did something vaguely similar in a project: I decided that every user story had to fit into a week and every Friday was release / demo day. Not exactly continuous delivery, but I think it was even before the term "agile" was invented...
No comments:
Post a Comment