There are lots of different kinds of risks. I'm trying to minimize the impact of the risk where one team delivers and then the other isn't able to. In the case of a UI, doing the UI first and stubbing out the back end would mean that you need to pull the work out if the back end team wasn't able to deliver in the release.
In your scenario, you might do some prototyping to alleviate the risks of the UI, but then hold off on the production implementation until the back end is there to support it (assuming these must be taken care of by separate teams). Or you might decide that the risk of the back end team not delivering isn't big enough to worry about it.
If you're able to do both parts at the same time (either by one team or by synchronizing the teams) then you can get the user feedback on the UI plus how it really works with the rest of the application.
Good point
There are lots of different kinds of risks. I'm trying to minimize the impact of the risk where one team delivers and then the other isn't able to. In the case of a UI, doing the UI first and stubbing out the back end would mean that you need to pull the work out if the back end team wasn't able to deliver in the release.
In your scenario, you might do some prototyping to alleviate the risks of the UI, but then hold off on the production implementation until the back end is there to support it (assuming these must be taken care of by separate teams). Or you might decide that the risk of the back end team not delivering isn't big enough to worry about it.
If you're able to do both parts at the same time (either by one team or by synchronizing the teams) then you can get the user feedback on the UI plus how it really works with the rest of the application.