A frequent question I hear is, “How much planning is required on Agile projects, and where do the business analysts fit in?” Great question.
The Simple Answer
The simple answer is it depends. But that’s a crap answer so let’s look at two scenarios: an existing application and a new application.
Scenario 1: Existing Application
This is where we have an in-production application and want to add a new feature. Depending on the size of your company and team, you may or may not have a business analyst as part of the Product Owner team. If you do, the BA will work with the customer to determine how the feature will work and what it will look like. Another term for this is a functional spec. This is the acceptance criteria portion of a user story, and defines done for the feature, and becomes the basis for user acceptance testing during a sprint review session. The amount of documentation can range from a few paragraphs to a few pages. I’ve read that you don’t want more than 5 pages of documentation for a user story, and my question to you is how much will people actually read?
Scenario 2: New Application
In the waterfall model of software development, all requirements were gathered in a single phase at the beginning of a project. For most software projects, this won’t work as things change and we can’t think of absolutely everything that might happen over the course of a project. Having said that, we do need a basis of functionality, and an estimate.
When we approach a new project, we ask for the who and what. The who is who will be using the application. The what is what each of these roles needs to be able to do on a project. From there, we can write the initial set of user stories, and our customer can prioritize the entire feature list. Once that’s complete we can create full acceptance criteria per scenario 1 for the initial release. Read more about writing Agile requirements if you’re interested.
Enough is Enough
Long story short, no one wants to read extensive documents, and the time it takes to write them can be better used elsewhere. Keep the amount of documentation for a single story to a minimum – just enough for the customer to test and the Team to start developing. Also keep in mind that documentation is not a replacement for conversation.
Other Posts That Might Interest You
