Semantic Werks

One of the central concepts in various agile software development techniques is the user story. Why go with a ‘user story’ instead of a rigorous requirements elicitation, culminating in a model of varying complexity? Is a story enough?

What is a ‘user story’?  These statements are (originally) from Agile Model Driven Development with UML2. Caution: as far as I can tell none of these statements is  empirically tested (or possibly even derived).

• “a user story must be able to be implemented by two people in a single iteration/cycle”
• “the user story card includes an indication of the priority”
• “You often create a stack of user stories during cycle 0 to identify the scope of your system”
• “Stories make it easier to divide the work into tasks than use cases” p 321
• “user stories are malleable and change during cycles”
• “because they’re small that they are very easy to work with and to evolve”
• “user stories contain so little information you will need to flesh them out a bit when you first work with them”
• “User stories are merely the starting point” for figuring out how to implement these stories.

Here’s an example, from the same source: “Parking passes can be paid via credit cards”.

So this user story takes two people pair programming about a week (for an average project). Really? Anyone who has worked on task-decomposition, whether in personal life or for work, would probably agree that the tough part isn’t determining goals, but figuring out how to achieve them. In other words, what concrete set of steps do I take to get this achieved? Presumably going from the story to the implementation is something a competent developer can handle, but it seems to me that a lot of design is hidden within that story: what does payment mean? What types of credit cards? Do we need to handle monthly and daily parking passes? And so on.

I would like to see a distinction drawn in talking about software development: We can talk about the process used to develop software: e.g., plan-driven, design up front, vs. work-in-progress limited lean development. But we can also talk about the artifacts used to drive the development. We could use stories and an onsite Customer. We could also use more formal requirements models, issue trackers, bug repositories, etc. I think these two are to some extent orthogonal. Nothing says the model must be set in stone before implementation.

Like the is-ought problem expressed by David Hume, we should be careful in making models not to merge tenses and verbs. One major purpose of modeling is to create a clear and accurate picture for decision-making. But in some models this clarity is obscured by including information on not just what the current state of the world is (indicative, is), but also what would be desirable (ought, optative – see Jackson in “Software Requirements and Specifications“, p. 125).

i* models are used for capturing agent-oriented intentional properties in a domain. One purpose of i* modeling is to enumerate alternatives and design opportunities. But the purpose is also to cast new light on the existing state of affairs — who depends on whom, etc. When these two states are combined, it becomes difficult to evaluate a design alternative: are we assuming Situation A will still hold; how can we be sure the Environment will still be the same; when is the shift in mood going to happen. For example, if I’m considering whether to introduce a technical wiki for storing common solutions in a business, does my i* model reflect the existing situation (no wiki) or the desired situation (wiki).  How can I distinguish between the two versions? Often we want to evaluate models to see how well certain decisions achieve strategic goals. How can we do this in a repeatable way if the same model is used for both current and desired conditions?

Another confusion is between structures of the domain and actions in the domain. We often say that a certain task satisfies a particular goal; but we really want to enumerate, initially, these structural properties of the domain — what exists now — and allow the designer to choose the implementation path. The tasks that are possible depend on the objects in the domain and certain basic constraints (time/space, physical laws, etc.). If we try to describe tasks that are necessary, or that exist already, we fall into a trap of descriptive analysis, where what already is confines our new design. Cognitive Work Analysis, for one, insists that structural properties in the domain be enumerated first, followed by tasks and strategies for accomplishing those tasks.

We should have 2 i* models: one enumerating the indicative, structural constraints the work domain imposes; the other providing rationale and alternatives for optative desiderata in the Machine-to-be.