We just presented “Requirements Estimation” at the Austin IIBA Chapter meeting. James Hulgan from ArgonDigital gave the talk to a group of about 35 people. His talk was about how to use our software requirements Estimator tool which you can download from the post or our requirements templates page. I captured some of the questions and comments from the group and wanted to share those here.

Q: Are you talking about estimating the work to produce the requirements or an estimate of how many requirements you will have (or how big the SRS is)?

A: This estimation technique is focused on how much work is required to produce good requirements. We actually do use some “counts” of requirements objects (like process flows, numbers of systems, numbers of reports, etc.) to get to the estimate, so you could in theory back out an estimate on the overall size of the requirements. Though this estimation tool does not do that.

Comment: If your project is strategic you can make a better case for taking longer on requirements. Very true – and if it’s not strategic, you should question whether to do it at all!

Activity: We do an exercise to estimate the requirements work for an audience voting system with very little context (a paragraph of the scenario)- admit it, you’ve been there! Well James asks the group: How many of you have given something in this level of detail to estimate and there were jokes this is better than the typical level of detail given before asking for an estimate. That said, people wanted to know more information like:

• How many stakeholders are there and where are they?
• Want to look at existing information architecture?
• What countries are going in?

Little did they know, we were about to talk about how you use those types of things to build up your estimate in a rigorous way. So great questions! But we didn’t give them answers yet, so they took some rough guesses at how long to do the requirements (eliciting, writing, reviewing) and came up with 2.5-3 months effort.
 

Q: My developers are remote, does that impact the estimates?

A: Yes typically it does impact the estimate because remote dev teams add a bit more overhead in communications and more detail is required in writing them down very explicitly. The estimation tool accounts for this by adding a buffer if your team is remote.

Q: Does the tool take into account having to do many review cycles?

A: It does assume you will have review cycles. You can tweak the assumptions if you find you do more review cycles than the tool assumes.

Q: Does the tool assume senior over junior resources?

A: It gives you flexibility to change the estimates easily based on which you have. Right now it assumes a blend somewhere in the middle, but there are low and high estimates provided in the tool and if you have a very junior team, you should pull in the high estimates.

Q: Do you know enough to vary the estimates based on types of projects – complex system versus simple?

A: These projects will vary based on inputs, so the estimates will vary. A more complex system typically has more integrating systems, more stakeholders, more process flows, more BDDs, etc.

Q: Does it assume a development methodology

A: Not at all. For example you can estimate use cases or user stories. The idea here is that the requirements effort isn’t really different between methodologies, the thing that changes is when those activities occur or which actual activities you do. So the estimator tool works either way.

Q: What if you have difficult stakeholders who maybe don’t know their requirements?

A: You could play with your assumptions to allocate more time to elicitation per stakeholder or more time per review. Or you could multiple the stakeholders by two and count each one as two!

Q: How do I know how many process flows I’ll have up front?

A: You have to do some analysis to estimate that! Typically there isn’t someone who can tell you it’s exactly 12. But you can learn enough with even an hour of learning about the project to know the major areas of functionality and how many process flows are likely in each. It’s just an estimate of course.

Thanks again to the Austin IIBA Chapter for the opportunity to present!