About
Exploring Solution Spaces, Keith Ray's blog on Software development and other topics.
Send comments to:
keithray@mac.com
| For Agile Training, eLearning, or Coaching contact: |
| Industrial Logic, Inc. |
| 866-540-8336 (toll free) |
| 510-540-8336 (Berkeley, California) |
| Links |
| xpminifaq |
| Résumé |
| “Adopting XP” Article 2002 (pdf) |
| “ Refactoring” Article 2006 |
| AYE Conference |
| Lucien W. Dupont |
| Elisabeth Hendrickson |
| Johanna Rothman's Managing Product Development |
| Brian Marick's Exploration Through Example |
| Esther Derby's Insights You Can Use |
| Laurent Bossavit's Incipient(thoughts) |
| Dale Emery's Conversations with Dale |
| Martin Fowler's Bliki |
| Creating Passionate Users |
Archives
Subscribe
RSS Exploring Solution Spaces XML
2006.Oct.19 Thu
Specification Documents as Tests
I was in a conversation with someone whose project is using Scrum. I was, if I remember correctly, trying to talk about the idea of how agile projects try to minimize the creation of artifacts not directly needed by the end-user or the developers.
She responded by talking about how essential the specification documents are for her team. I asked her "Who reads these documents?" and she said that the testers do. (NOTE: not primarily the programmers!) I then suggested to her that maybe in this agile development process, the testers should be writing these documents instead of reading them. And not writing them as static documents, but as executable tests in a form understandable by the Product Owner and programmers. Her face lit up with understanding.
I hope I helped. If she recognizes my attempt at recounting this conversion, I hope she will let me know if this helped her team in their adoption of agile practices.