card when doing a stand-up meeting. Meaning arises from the arrangement of people and things in the environment.
Compare this with the sterility of Cube World. Although an individual might have a sufficiently rich environment for her to come up with a theory, it is almost certain that the theory will be about the computer and not an affair of the world. There definitely is insufficient context for a team to build a consensus gestalt.
How about electronic artifacts - using RallyDev and Rose and similar tools to create a shared online environment? Maybe, but only if everyone has a 50" monitor and can have lots (lots!) of windows open at the same time along with the ability to rearrange the representations in those windows with the same flexibility afforded by a physical environment. You also will need to mix in video and audio feeds to get the people into the virtual world. Maybe, but not likely.
A story is not a requirement. A backlog is not an inventory.
A story card is an evocative device  that recalls to mind past conversations and context that are far too rich to capture in any representational model. [A story card can also be a reminder of the need for future conversations.] A story card is an exemplar of the kind of external artifact necessary for gestalt formation.
A story is a fragment of a theory. A backlog of stories is a model of the current understanding of a theory - or a subset of that theory. The product backlog, captured and displayed as a set of story cards is a visual and tactile artifact of the group's current understanding of a theory. A sprint backlog is the same with added focus.
Stories are written by customers/users because the point of theory is an understanding of an affair of the world. Software developers, traditionally, have very little understanding of the world; and, stereotypically, have very little understanding of affairs.
Stories are written and told to develop and expand a whole-team gestalt. Stories are not created to be units of work that enable Scrum project management.
Pair programming is micro-theory building using tests and code as the external artifacts.
Each pair extends the shared theory with character development (objects) and dialog (messages, object interactions) in service of the overall plot (the affair of the world) being advanced by the code. Judicious mixing of pairs ensures that the entire group shares in the same gestalt. Collective code ownership accomplishes much the same goal - ensuring that everyone shares the same theory.
Even something as prosaic as a burn-down chart can contribute to theory. If we truly have a theory we know things about the world and about the software - including how difficult it will be to translate a world thing into a software thing. Burn down charts, along with similar charts for estimates, provide the feedback that confirms - or denies - our current theory.
Theory is dynamic in at least two dimensions. First, the theory is about an affair of the world and hence is dynamic to the same extent that the world is. Second, theory is emergent over time, as it expands and morphs. Embracing change, iterative, explorative, and incremental development - the core of agility - is the only way that theory can be constructed.
Coulda, Woulda, Shoulda
Agility and agile practices, properly construed and used, are a silver bullet!
Unfortunately, most of what passes for agility is merely the application of techniques and method to solving the accidental difficulties of software and the production model of software development.