In this approach, your trunk contains a release-ready version of your code, and contains only stable, fully-tested features. Each development team has their own development branch, which they use to progressively implement application features (user stories). Whenever a feature (or story) is finished, tested and deemed production-worthy, it is committed to the main branch. So, at the end of the iteration (sprint), the release is whatever is in the main branch at that time.
This approach is well-suited to Agile environments, though it needs a little discipline to ensure that developers only commit code to the various branches in an orderly manner (Henrik refers to this as the "branch policy" - one branch might accept unit tested code, whereas the main branch will only accept fully tested production-ready features).
Using this strategy, your Continuous Integration setup will be a bit more complex, with a CI job (or several CI jobs) for each active branch.
This approach, incidentally, can also be applied to other more traditional projects, especially in a maintenance phase. Your trunk is your stable production version, and branches are used by small teams working on new features or bug fixes.
He also shows how this strategy can scale upwards, and work for multiple teams working on the same project.