4 ms·

Why Agile should focus on Problem Statements instead of User Stories

1 points by jdubray 13y ago

dragonwriter 13y ago
The consistent use of "solution" as a verb in place of "solve" makes this hard to read; especially things like saying "every problem must be solutioned" (oddly enough, the BOLT diagram uses "solve" as the verb.) 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.
- jdubray 13y ago
  I added some comments to the post to explain that the structure of a User Story has already a foot in the solution space. I view this somewhat as an issue. 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.

1 points by jdubray 13y ago

The consistent use of "solution" as a verb in place of "solve" makes this hard to read; especially things like saying "every problem must be solutioned" (oddly enough, the BOLT diagram uses "solve" as the verb.) 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.

jdubray 13y ago
I added some comments to the post to explain that the structure of a User Story has already a foot in the solution space. I view this somewhat as an issue. 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.