For example their section on how use cases and user stories differ are vague and generic. It explains how user stories and use cases are similar but how they differ is simply a list of generic, non-useful tripe such as "flexible", "better", "easier", "increased understanding", "easy focus", etc.
I left this article not knowing if this is just a slight re-branding of every other methodology out there nor any compelling information saying why I should or should not use this one over others. Granted I didn't read the entire thing but I read the beginning, end and skimmed the middle. You should be able to convey your value in the first few sentences if you want people to use your methodology. In my opinion anyway.
I get in big teams you need some form of process but I feel like if your process takes longer than a page to articulate then it's never going to be followed and is a waste of time.
i wasn't particularly confused with the terms use case vs user story, but if i didn't know those concepts already, the article would not have explained them to me.
(fwiw a use case is a series of steps that a user must take to complete an action, but a user story is usually a sentence told from the viewpoint of the user such as "as a user, i want to log in so i can add a new post")
The introduction of "slices" appears to acknowledge that. The problem is that like functional decomposition in structured programming, constant re-arrangement of the functional "tree" representing the problem will likely result.
