Team 1: Dev Team for handling feature stories and bugs of same
Team 2: Maintenance Team for handling bugs of previous releases
Team members exchanged between Dev and Maintenance team every release so that morale of Maintenance team doesnot go down
Pro : All features are delivered as per plan, Team is not disturbed
Con : Team may have to work fix bugs on the features they have not
worked on.May take more time to fix issue and originator of the issue
will not get to know what mistake he has done and can do the same
mistake again, code merging is required
Probably, this risk can be mitigated if in sprint retrospective or
release retrospective - dev and support team handshake occurs.
Require Knowledge transfer of application from dev team to
maintenance team in every release end
With Model one you may achieve "All features are delivered as per plan, Team is not disturbed" but the features are not actually complete because there are bugs still to be closed. This can lead to extremely dysfunctional behaviour where delivery of a feature is more important than whether it actually works, is secure and if the code is of decent quality.
Have each team responsible for maintaining their own work. Task them with completing work pulled into each sprint to the "definition of done". Where work was not properly completed in a previous sprint and takes effort to fix in a future sprint you are getting a more accurate impression of your actual velocity by 'losing' time fixing the issues later. The time lost later should really have been spent in the original sprint on that task rather than on starting another one.
By creating two teams you immediately introduce imbalance. Maybe one week there is a lot of project work to do, but the next week the focus needs to be on fixing production bugs. With the two teams concept you are likely to have one team overworked and one team under-worked.
One of the big benefits of Scrum is to have a consistent team. This allows us to predict the capacity of the team. If you change the team members frequently it will be difficult to predict capacity.
You can end up with a false impression of progress. The development team appears to be moving along quickly, but there is a backlog of production bugs building up. All appears well, but the reality is very different.
It does not encourage pride in the quality of the development. If another team has to fix the production problems the development team is insulated from the mistakes they make.
Model 2 would be my preference. You rightly point out that predicting the time to fix bugs is difficult. That is one of the reasons teams often focus on prevention rather than fixing issues after they have happened. Examples of this approach include the use of TDD, continuous integration and automated regression testing. Spend time up-front promoting quality so that the rate of bugs is reduced and then forward progress becomes more predictable.
I get the impression (possibly incorrect) that your teams send too many bugs into production. If this is the case, you might want to review your current engineering practices and see how to tighten it up. You can ask the team in the next retrospective and implement the top suggestions on priority.
Due to our specific application we actually have new developers run bug support to help train and get use to the system. As they grow they take on projects and handle bugs in the same fashion you discuss in Model 2. Important customer support bugs get dedicated support from our new developers. If the issue is big enough it goes into the features queue and the team works on it. If the issue is an avoidable mistake or what we call a bug kickback (bug created by push or bug fix) then it's escalated to the member that creates it and we hold them to their schedule still. We do see some push on the schedule but this usually is accepted by our business as important bugs that affect enough customers get their attention, developers are trained, and features don't take priority when the system is "failing."