5

Model 1:

  • Team 1: Dev Team for handling feature stories and bugs of same sprint/release
  • 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

Model 2:

Decide , these many bugs team will fix every release - lets say 10 bugs So team velocity is lets say 20 story point per sprint (excluding bugs which will be mentioned separately in status report)

  • Pro : All fixes will be carried out by those who were responsible for that so they will realize their mistake
  • Con : Not sure how much time each bug will take , sometimes it takes few hours and sometimes a day so its going to seriously hamper feature story plan

Please share your views.

Improve this question
9
  • 1
    This old post may help you: pm.stackexchange.com/questions/8098/…
    – Zsolt
    Oct 18, 2015 at 10:11
  • 1
    @Zsolt, added your link in Model2 ...its not a comparison. But its a very good post that tells about Model2. It will definitely help.
    – Dimple Sahani
    Oct 18, 2015 at 10:35
  • "Not sure how much time each bug will take". - work on this. Measure velocity in the same way as with features.Rely on teh judegment of your team. You missed "Merging is expensive and awful" from your model 1 cons.
    – Nathan Cooper
    Oct 19, 2015 at 8:35
  • @NathanCooper, updated the cons of Model1
    – Dimple Sahani
    Oct 19, 2015 at 8:53
  • 1
    @DimpleSahani My advice would be to compile and summarize the recommendations and approaches you find, and then discuss it with the teams and ultimately let them decide. After a reasonable amount of time has passed to allow them to evaluate it, revisit it and keep/change it as needed.
    – Jeff Lindsey
    Oct 20, 2015 at 14:26

5 Answers 5

Reset to default
7

Model 2

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.

Improve this answer
1

Some disadvantages of Model 1:

  • 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.

Improve this answer
0

I recommend the same Team for handling features and bugs

Team members exchanged between Dev and Maintenance team every release so that morale of Maintenance team does not go down.

Try to keep the teams relatively stable, even if they switch from one project to another. This is because teams take time to gel together. Also, you can better predict velocity this way.

excluding bugs which will be mentioned separately in status report

All work that the team will do in each sprint should be accounted for. So, estimate the bugs also with story points. See Should Story Points Be Assigned to a Bug Fixing Story?

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.

Improve this answer
0

We use a hybrid of both methods.

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."

Improve this answer
0

Have a look at this stackexchange link

I could have added this in comments but I dont have enough points to do that

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.