Why Agile should focus on Problem Statements instead of User Stories
b-mc2.com
b-mc2.com
But once you get past that and some other odd uses of language, this seems to be an argument that the units of work entering the development queue in an Agile project ought to be the output of a process of decomposing problem statements and then, when the appropriate level of focus has been reached, developing solutions to the decomposed problem statements.
I don't have any problem with that, but I fail to see how it offers anything new. Aside from what appear to be gratuitous swipes at "value" and "user stories", a halfhearted attempt to propose new jargon (except that the terms aren't defined, each just has some vague statements made about it), and a claim that this somehow increases the organizational value of the PMO, this seems to be exactly how most works on agile or lean methods I've ever seen have suggested that work items (whether they are called "user stories", as is common in many agile approaches, or not) are generated. So I don't see what new is being offered here, or what the concrete problem being addressed is.
The relationship between a problem and its solution (one of many) is a graph of states, transitions (decomposition of the problem) and actions (the solution of each transition).
The problem I see with User Stories is that not only we encourage a solution centric thinking but the articulation between the problem and the solution is convoluted (not cleanly expressed as a graph) and often forced fit into a hierarchical tree in tools like Rally.
I have been part of teams who struggle to relate user stories together and I think this is a core problem, there is no clean decomposition possible, like you could achieve with problem statements.
Hope this helps, thank you for your comment.