Will analysing complex requirements in short agile sprints result in requirement errors?

On agile software development projects agile business analysts are taught to delay detailed analysis until the time that information is needed. This stops the business analyst from having to undertake significant rework to accommodate changing requirements. We are also told to work in short iterations or sprints. As all business analysts know some complex requirements can take time to elicit, synthesize, communicate and validate. So it does raise the question:

Will analysing complex requirements in short agile sprints result in requirement errors?

There are ways of managing requirements on agile software development projects to reduce errors that could be associated with trying to deliver complex requirements within the tight time available on short agile sprints:

Two levels of analysis

On Equinox IT agile software development projects we undertake analysis at two levels. The initial level of analysis is usually done prior to the sprint, and consists of establishing high-level user stories with acceptance criteria - just enough detail from which to be able to plan and estimate the task. We then elaborate acceptance tests (which also act as detailed requirements) as our in-sprint activity. So, this can help manage the business analyst workload within each sprint.

Sprint planning

Agile projects normally have planning sessions prior to each sprint or iteration and work is assigned based on product backlog priority and also what is achievable in the available time. If you are working on a sprint of two weeks and you are trying to fit a requirement within that sprint, then you need to have the unit of work be small enough so that it is achievable. A greater number of smaller tasks is also easier to manage from a workflow perspective. So, if it’s just a single algorithm for calibrating salary based on three inputs, then you should be able to do that within a sprint comfortably, while also undertaking detailed analysis for other user stories.

Reducing time to analyse requirements

Complex requirements do take time to get right. On agile software development projects at Equinox IT we often use a tabular form to express requirements as sets of test scenarios. This can help accelerate requirements elaboration, uncovering ambiguities and missing requirement very quickly

Working as a team within the sprint

Agile teams are often cross functional and in these collaborative teams you will normally find that the business analyst isn't the only person involved in analysis activities. For example, acceptance test definition, which as stated above is our way of documenting detailed requirements on agile projects, should be done ideally with the participation of the developer and the tester. The developer knows how they are going to implement and automate the tests. The tester is good to have involved because they have a testers' mindset. We find this collaborative approach is quicker because more people are involved and you handle the questions immediately rather than being interrupted later forcing you to switch tasks. Effectively you have a continuous feedback loop during the process between the developer, the tester and the business analyst.