Rather than being given the time they need to create well-crafted requirements, business analysts are often required to create their requirements specifications under an imposed deadline. This practice typically leads to stressed business analysts and poor requirements because either the requirements aren’t all documented or they are poorly documented. Occasionally the business analyst gets the opportunity to estimate their business analysis work, even though the PM may choose to ignore that estimate. Unfortunately, there are no widely recognized industry standard approaches to estimating the requirements effort.

Given that dilemma, we developed an estimation approach for the requirements effort that we use on all of our projects. This approach has three facets to the estimate, to allow the business analyst team to most accurately estimate the work by comparing all three facets. The three facets include a percent of total work, a developer to BA ratio, and an activity breakdown that uses basic resource costs to get to an estimate. All three facets are based on actual work estimates we have honed over the years on our projects.

The first facet of the estimate uses a percent of total work, specifically 15% of the total project should be allocated to requirements alone. So if the full project is 1000 hours, we estimate 150 hours of requirements work.

The second facet of the estimate uses a ratio of developers to business analysts, and we use 6 to 1, meaning that six developers require one business analyst. The thought is that one business analyst can produce enough requirements to keep six developers busy. The business analyst also will be helping QA, PM, the business, and answering questions for the team, but the point is that all of those resources are also to scale for six developers, so this estimate encompasses all of their work. In a COTS project this ratio changes to be 3 developers to 1 business analyst, because there are still many selection and configuration requirements to be elicited and documented, but the development team is smaller since the code is largely purchased instead of developed.

The third facet of the estimate uses the actual activities a business analyst performs, based on estimates of numbers of various artifacts. The business analyst can estimate things like the number of process flows, user stories, screens, and reports and then make reasonable assumptions based on those numbers of how many other requirements artifacts are needed. Then based on time estimates per activity, they can sum up a total requirements effort estimation.

We created a tool for calculating all three facets of the requirements estimate. The assumptions in this estimation tool are based on ArgonDigital’s experience on years of actual projects. That said, some of the assumptions will have to be tweaked for your own organization. For example, if you have more or less experienced BAs, some of your estimates per activity may vary.

The requirements estimation tool has three tabs. First, there is a summary where you input reasonable guesses as to what you know about your project (in yellow) and the three facets of the estimation are calculated accordingly (in green). Second, there is an assumption tab where you will update some of the calculation assumptions based on your organizations needs as they vary from our starting point. Third, and most importantly until you are familiar with the tool, the instructions tab is where you will find detailed help on how to use the estimation tool.

NOTE: We have updated the tool to an .xls format; some reported issues downloading .xlsx files.
We hope that this estimation approach helps you estimate your business analysis requirements effort. You can download our requirements estimation tool if you are interested and adapt it for use in your own organization.