In a traditional development practice, a product manager writes a long document describing the software requirements. Hopefully the document is diagram heavy, clear and concise. The document is handed to analysts who break the requirements down to development tasks and a project manager develops a schedule and assigns resources to tasks.In my experience, this rarely happens. In the real world, requirement documents are rarely complete and the software developers themselves are developing the architecture directly from the requirements document. Things look good for the first few weeks of the development cycle until the requirements change and the product manager updates the requirements document. Hopefully the product manager turned on ‘track changes’ so that the developers can see the differences. But even in this scenario, multiple changes over the course of a larger project are difficult to document and track properly. The result can be inconsistent requirements. In addition, the developer is probably getting tired sifting through the changes in this document and asks to have meetings to ask questions. The developer listens, writes a few notes and goes off developing. Maybe a detail is missed here and there or something is lost in the translation. Skip ahead a few weeks and the product manager is recording defects.If only we could simplify. Maybe have the product manager and developer talking right from the beginning thinking through the designs and requirements together. After all, developers need to understand the business and lets face it, the technology isn’t all too complicated today for product managers to talk tech with a developer. Maybe the requirements of a feature can be drafted together as a… a… short story. Yes, a story. Something everyone can read and understand. But lets make sure that some of the specific requirements are also written down in a clear concise way so there’s no ambiguity on the deliverable. We should probably call these acceptance tests. Now that the developer understands the feature well, maybe she can even provide a time estimate. Hmm, the product manager says, that estimate is kind of high, can we simplify and do it cheaper? Sure she says, but only if we simplify these requirements. The product manager thinks about it and agrees. The developer then commits to this contract and does her best to complete it as specified. That’s not too difficult because she understands the story and has all the details on the one page contract sitting in front of her as she develops the code. When the contract is done, she reviews the feature with the product manager along with all the acceptance tests.

The product manager and developer repeat this approach again and again. After the fifth iteration, the product manager thinks to himself, “Wow, this way of working together is really agile.”