My answer is “yes” but not the old type of Business Requirements Document (BRD). I think there is a role for a new type of on-line BRD – one that can easily evolve during the project. Some argue that TDD is replacing this need. But I think there’s a place in the Agile process for capturing the business requirements/information in parallel with the development tasks that ends up on-line and useful/readable by all. It happens DURING the process, NOT up-front.
I think anyone who believes in Agile knows that the biggest problem with a big fixed documentation up-front, especially in Word, is that it gets out-of-date quickly and then is just a pile of often-misleading words. OR it’s held as the “bible” and then people become possessive of it and build some big process about how to any requirements mismatches, design flaws, etc. become change request-type issues and there we go – Waterfall all over again.
I believe the BAs/PMs are more likely to feel they can retain project oversight if there’s an on-line tool to track the product backlog (in high-level terms) and bring forward when time to implement it and where you can expand/refactor/capture details as you go along. Where stories can evolve into an on-line knowledgebase/repository that people (like the Call Center, Services group, new hires) can read and reference.
Of course, all projects, Agile or not, have requirements that are (hopefully) based on business needs. Some teams are struggling with their PM/BAs wanting to create a large document at the beginning of the project containing detailed use cases with every possible variation on every requirement. Some are having trouble convincing the PMs/BAs that a Product Backlog with user stories instead of fully documented use cases is a suitable method, with detailed analysis taking place during a sprint.
I think the hesitancy from BAs/PMs is a feeling of a loss of control when they are told to just write down “I want this …” stories, put notes on a board and work “in the air” (verbal communication mainly, not written). Some may argue that is a “lack of trust” – but I argue that PMs are also builders/designers who want to end up with “their” product at the end, their BRD. That still can be a valuable artifact. As long as it’s something that evolves with the product seamlessly and isn’t a wall blocking the project.
That’s where Software 2020 fits in beautifully. The prior blog, “Automatic Documentation – How we use Software 2020 to build Software 2020” describes the automatic way to use Software 2020 for tracking tasks, communicating between the team members (PMs and Developers) resulting in both an outstanding product and nice on-line knowledge base repository (aka BRD).
Software 2020 provides rich text online storage that is:
Jan McCleery - from the Duck Pond 