Mostly similar questions than this are about scrypt and PBKDF2.
The execution time for slow-hashing (password-based key derivation) must be as long as you can afford (i.e. as long as your users are willing to wait for password derivation). If you use two functions, one taking another as input the time will normally grow, and you get less benefits than by picking stronger of the functions. However, if you can run the functions in parallel then you can get benefits with little cost.
To find more details, read on.
Benefits of scrypt
A common attack against key derivation functions is to try to brute-force underlying key material. In case of actual password-based key derivation functions, the functions attempt to ensure there is significant workload in trying to brute-force password (slow-hashing concept).
The benefit of scrypt is that it requires more memory. The usual cryptographic functions can be implemented in ASIC (or FPGA) in very small piece of silicon.
Large memory requirements are usually not a problem for PC or smart phone, but implementation of brute-force will take lot more space.
Benefits of PBKDF2
PBKDF2 (from PKCS#5, RFC 2898) is old and tried function, which is much better than old practice of using e.g. hash instead of password-based key derivation.
PBKDF2 allows to choose what PRF to use.
NIST has made recommendation for PBKDF2, and thus PBKDF2 is the function that can be the option to use in systems having to be compatible with FIPS (in case the PRF is FIPS-approved and the library or chip implementing the function has been properly certified).
Benefits of bcrypt
bcrypt falls in-between. It uses more memory than PBKDF2, and thus kind of represents compromise between PBKDF2 and scrypt.
scrypt's paper explains all these functions and compares them from perspective of password brute-forcing with ASIC.
For implementations where new relatively new algorithm is fine, I'd use just scrypt. In case it is needed to have old standards compliant algorithm, I would go with PBKDF2.
In combination where for some reason it is necessary to use three algorithms, well, bcrypt would be third.
If your device has more execution cores than one, you could try to run more functions in parallel. Many implementations of PBKDF2 and bcrypt parallelize well.
Running functions in serial gives questionable combination and its efficiency is to be questioned.
For similar question nightcracker offered answer where he runs PBKDF2 and scrypt. This answer is easily parallelizable.
Instead of xor, the multiple results could also be combined with e.g. NIST SP 800-108 key derivation functions.
If you want to be very careful, you might want to have different salts for different algorithms if you are ware of possible implementation details allowing shortcuts for brute-forcing. But this comes with great cost: you need to store lot more data per user.
Going easy: Just use scrypt.
Harder: If you really really want to use two functions you might want to consider the suggestion of parallelization.
Note: in any case, please spend some time benchmarking so that you choose good work-factors for functions. The most common mistake in use of PBKDF functions too low work-factor.