In most projects some amount of analysis is required. With an agile method like Scrum there’s no room for a separate analysis phase. It is assumed that analysis can be done concurrently with design and build activities. This is often true when the business process is known.

Sometimes also the business process needs to be determined. This is the case with new processes but also when process optimization is needed. The problem with this is that analysis can take a long time and often software development is stalled. Another potential problem is that the people whom do the analysis are not the same people as those that build the software. A transfer of knowledge is required and that’s something to be avoided when possible.

The traditional waterfall approach of course is not the solution. This approach creates other, much larger problems.
So can a substantional amount of analysis be done in an agile manner?

The analysis is done in a separate project “waste” is created in two ways; there’s the waste of (extensive) documentation used for knowledge transfer and there’s the waste of waiting (between analysis and design). Both should be avoided where possible.

I think there’s not one single successful approach but I’m reasonably happy with the approach we’re following at my current project.

First of all, we have introduced a second Product Backlog. This Product Backlog contains the user stories (risks, problems, whishes) on the process level. The Scrum team consists of analysts. The companies director is the Product Owner.
Each sprint the analysts create a draft business process model. In collaboration with the Product Owner of the Design & Build team they also create the user stories for the other (regular) Product Backlog. These user stories are derived from the draft business process model.

Both teams are co-located in the same room. The draft business process model is used as a guideline by the Design & Build team. During the Design & Build activities the analysts are available for questioning and support.