So this is going to take some time to read and process but I'm not convinced people should (I mostly skimmed). It's essentially another methodology for getting work done that, like all the others, are so close to how each other work it may not be useful to really understand or switch between any of them. Even if you use this methodology I'm not convinced it's useful or helpful to understand all the intricacies of it.<p>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.<p>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.<p>I get in big teams you need <i>some form</i> 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.