Home > Articles > Software Development & Management > Agile

  • Print
  • + Share This

The Stories of San Michele

A certain knowledge of system requirements is traditionally expected to spring fully formed from the mind of the customer, rather than to evolve with their growing understanding of a solution. These requirements are stored like grain, as if once documented they become more enduring than the need that evokes them. Yet it is only natural that requirements swiftly rot, along with the analyses that derive from them.

[This is] the tide of nature, An eternal decay and renewal [Lao2000]

Requirements are forever reinterpreted within unintended contexts. Layers of translation like Chinese Whispers combine to tangle the project. Each requirement has a range of misunderstanding, and their combination stretches almost to a Cartesian product of these ranges. When requirements are combined with nonfunctional qualities, the situation may be made only worse, as these qualities provide no means to assess associated costs and make tradeoffs.

Requirements are also vulnerable to flights of fancy. Even commonplace fantasies entail considerable expense for little real benefit to a customer. When such expenses are eventually experienced, large swaths of the requirements are arbitrarily discarded, and development becomes mired in half-solutions. New projects spring from the dregs of the old to entice an interminably dissatisfied customer.

To nail down every requirement in sufficient detail that its meaning is unmistakable may require more time than the provision of a working solution. The more precise the specification, the sooner change obsoletes it, and the most detailed requirements leave developers little freedom to apply their skills to improve a solution.

So it seems the greater a business's investment in documenting its requirements, the deeper its dissatisfaction with the deliverable that results.

The XP user story cuts cleanly through this Gordian knot. A user story does not define a requirement in a traditional sense, but an underlying business need. The system requirement for a front door, for example, might read

There shall be a panel placed symmetrically such that the user, upon turning and pulling a knob opposite three or more hinges, shall cause the panel to swivel on its vertical axis so that a human of standard dimensions may operate said knob with either hand, but first requiring the unfastening of a lock, the lock being a latch only reset by the insertion of a key conforming to the national standard for keys, the said panel being of no less than two inches in thickness and made of a wood or some other material conforming at least to the durability and stiffness of . . .

A Front Door use case diagram may be no less complex. Such descriptions seem pedantic and unlikely, yet the author has been presented with similar requirements for less commonplace mechanisms that roll on to fill hundreds of pages.

A corresponding user story would simply say

The owners and their friends, but no one else, need an easy way to enter the house from the street.

This distinction is sufficient that skilled artisans can suggest solutions and give estimates of time and cost for consideration by the customer. And no more.

At first working with such stories may seem sloppy and incomplete, but the key to their effective use is iterative feedback. Perhaps the most beautiful house on Earth, the Villa San Michele on the isle of Capri in the bay of Naples, was constructed in just this way. Its creator and first resident, the Swedish physician Axel Munthe, described his process.

Nobody knew so far what it was going to look like, nor did I. All we had to go by was a rough sort of sketch drawn by myself with a piece of charcoal on the white garden-wall. I cannot draw anything, it looked as if drawn by the hand of a child. [. . .]

This is the loggia, [I said,] with its strong arches, we will decide by and by how many arches there will be. Here comes a pergola leading up to the chapel, never mind the public road running straight across my pergola now, it will have to go. Here looking out on Castello Barbarossa comes another loggia, I do not quite see what it looks like for the present, I am sure it will spring out of my head at the right moment. [. . .] Here comes a large terrace where all you girls will dance the tarantella on summer evenings. [. . .] This is an avenue of cypresses leading up to the chapel which we will of course rebuild [. . .] and here looking out over the bay of Naples we are going to hoist an enormous Egyptian sphinx of red granite, older than Tiberius himself. It is the very place for a sphinx. I do not see for the present where I shall get it from but I am sure it will turn up in time. [. . .]

The whole garden was full of thousands and thousands of polished slabs of coloured marble, africano, pavonazetto, giallo antico, verde antico, cipollino, alabastro, all now forming the pavement of the big loggia, the chapel, and some of the terraces. [. . .] What had once been Maestro Vincenzo's house and his carpenter's workshop was gradually transformed and enlarged into what was to become my future home. [. . .] I knew absolutely nothing about architecture, nor did any of my fellow-workers, nobody who could read or write ever had anything to do with the work, no architect was ever consulted, no proper drawing or plan was ever made, no exact measurements were ever taken. It was all done all' occhio as Maestro Nicola called it. [Munthe1929]

Just as Munthe described, XP user stories are kept to a fine granularity so that the misunderstandable range of their solution is small, so estimates can become firm, and so stories can be changed, reprioritized, or discarded as customer perceptions of need change. Because only a vision and few specific details are described, XP developers must consult customers directly and regularly to transform a story into concrete engineering tasks. XP's interlocking disciplines nevertheless ensure the customer's vision is realized to the extent permitted by its budget. The customer is able to direct the work in easily manageable chunks. Developers are never asked to solve irrelevant or artificial problems. The user stories become foci for development, not abstractions for debate.

  • + Share This
  • 🔖 Save To Your Account

Related Resources

There are currently no related titles. Please check back later.