Rule of Thumb: One Architect/Analyst can generate enough work for two Developers and one Tester, structure your project teams in this ratio.
Your Business Analysts are the face of your project to the widest number of business people. It is their job to gather and consolidate all the needs and desires of the business — the Requirements — within the project scope, in such a way that the business people can understand and approve the result (“Yes, that is what I will pay for.”), and that designers/developers can build the system that will meet those needs (“Yes, I can build something that will do this.”).
If your project has relatively few types of business people who will use the system, and you are creating new software, especially when it is to support new functions such that the business does not yet know all of its needs, then by all means, gather the users, business analyst, developers and testers in a room and pound out the system in a agile, iterative approach. If the IT participants can perform multiple roles, then the ratio stated above does not matter.
However, I am betting that 75% to 90% of the time, your project will not look like this. Even if the user scope is narrow, it is still a common tug-of-war with business management to get users involved to the extent needed for agile approaches; or the knowledgeable users you need cannot be spared, and substitutes are provided who cannot give the team what it needs without checking with management or those people you really wanted.
The other reason is that many projects have a wide number of potential users, with different (and maybe what looks like conflicting) needs, possibly spread out over multiple locations, perhaps literally spread around the world. So, someone has to deal with these complexities, and consolidate the results so that the appropriate solution can be delivered.
These days, that person is what is now commonly called the Business Analyst, charged with documenting the Requirements for the project. How Business Analyst’s do that, and what the Requirement deliverable looks like and contains, is a topic for many books, and there are many, from Yourdon to Wiegers. This should be a crucial part of the methodology you use in your shop, whatever the specific techniques or approaches it contains.
In essence, a methodology is used to make delivery of a solution faster, less work, and with a quality result. One of the ways it does this is by fostering communication between participants by providing a common language and structure. This is crucial for the business analyst’s job, as their role is essentially communicative; their deliverables are intermediate, used to assist in creating the final delivered system. So, an important test of your methodology’s effectiveness is if your developers can take the Requirements and build what they say is needed, without the developers having to spend more time trying to get any more detailed information that the Requirements did not contain.
When this is the case, my experience has shown that a Business Analyst working with business people can, after completing an initial part of the Requirements, provide enough content to the rest of the team to keep two developers occupied with design and coding efforts, which is where the most time on your project will be spent. Separate testing of the new code produced by two developers will normally require one tester; many companies actually combine the Business Analyst and Tester roles.
I have found this 1-2-1 ratio to be a good rule of thumb. It may vary in some projects; if you have an experienced Business Analyst, they might be able to provide enough content for 3 or 4 developers, but not much more than that.
Next Time: It is the Deliverable that matters, not the Task.
@dwwright99 on www.twitter.com …
