Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Due to health condition of one of the scrum member, he has to leave the team.

My question is, do I need to start a sprint planning session again? or change the burn-down chart? or ask all the team members to bite the bullet and do extra work to meet the target?

Thanks

share|improve this question

4 Answers 4

up vote 17 down vote accepted

You need to de-scope the least important stories and move them to the next sprint. Your capacity has changed and the sprint should reflect that.

If the customer adds a new, high priority big story, what do you do? Accept it and add it to the sprint? Re-plan? Change the burn-down chart? Bite the bullet? No. You de-scope other stories as you don't have capacity.

This is no different - the circumstances have changed and your team can no longer commit to the initial scope.

share|improve this answer
    
We have already done the sprint plan meeting. I thought once the plan meeting is done, everything is set in stone. yes/no? –  janetsmith Oct 4 '11 at 6:51
    
@janetsmith - Nothing is "set in stone". What would happen if there was a flu epidemic and you lost all of the developers? –  Oded Oct 4 '11 at 7:46
    
Is that mean I have to start a sprint planning session again? Sprint planning session seems quite involving. –  janetsmith Oct 4 '11 at 18:53
    
@janetsmith - No, you just keep dropping the items that are lowest priority in the sprint, until you can achieve the remaining stories with the capacity you now have. –  Oded Oct 4 '11 at 18:56
  1. No. You don't ask people to work extra hours. Do you want more to leave?
  2. What is a burn-down chart? It's the graph of what points are completed against the graph of what points you need to complete before the deadline. So why change it? Keep graphing and you'll see the effect that losing a developer has and can keep the customer informed.
  3. The customer can use that information to descope or extend the deadline. What they can't be allowed to do is say that they want more resources. Resources come when you find them and go when they feel like it and forcing in the wrong person quickly will not solve your problem. This is particularly true as the deadline approaches.
  4. If you're going to hire someone, expect that to take time too, so the cost will be more than one developer's hours, and the gain will not be immediate.
  5. Point out to the business that if they don't want this to happen in future, they need to hire too many resources at the start of the project and stay ahead of the expected requirement until close to the deadline (when, because they're ahead, they can lose half the team and not replace at a time when the remaining devs don't need to spend time training).

Disclaimer: All of this comes with the caveat, "in a perfect world." Now get as close to it as you can and you'll be ok.

share|improve this answer
1  
If an important deadline is coming up then it is okay IMHO to ask the team members if they are willing to put in some extra hours. It is usually okay as long as it is an uncommon occurrence, an exceptional incident, and you ASK the team to do this, not TELL them. The majority of the time you will be surprised how the team will proudly step up and deliver. The caveat is that they have to have respect for you and feel that you respect them in turn. –  maple_shaft Sep 30 '11 at 22:07
1  
If you're in need to put in extra hours, you overcommitted or something came in between that made it unable to complete the work the team committed too. In both cases you have to inform the product owner in time so he can take the appropriate action (e.g. remove some stories). Scrum says the team should work at a sustainable pace of 7-8h a day, you shouldn't work extra hours. –  Bart Sep 30 '11 at 23:33
3  
@maple_shaft: You ask me to do extra hours because I screwed up, or even one of my teammates screwed up (and can't do it all himself this time), or because I've overpromised, I'll do it in a heartbeat. Ask me to do it because management failed to account for the possibility of someone leaving, I'll not take it quite so well. –  pdr Oct 1 '11 at 1:22

As a team member or scrum master do nothing except informing product owner about the situation. Your team already made a commitment to some amount of user stories based on some expected capacity. Something bad happened and one of your team members cannot continue in sprint due to health condition. That can happen and nobody can blame him or you for that.

It is up to product owner to decide what to do next. It is obvious that you will most likely not deliver what you committed. Product owner can let the sprint continue as is so that you complete as many user stories as you can without missing team member and unreasonable overtime or she can decide to stop the sprint and start a new one - but it would be quite drastic.

Descoping is dangerous. Sprint should be a safe zone for the team. It is part of agile principles to empower people. Team is empowered to make a commitment. Once you allow commitment changing during sprint it can soon become a common practice and the whole point of commitment and safe zone will disappear. You will get chaos with continuously changing sprint target.

share|improve this answer

Realize that scrum has velocity to help manage that.

My understanding is that your velocity will adjust to the new team over time. Certain places even allow to estimate a decrease in velocity, to help better manage when team members either leave, or even just go on vacation.

share|improve this answer
    
So so. Certain places allow even a decrease of velocity. How generous of them. Did you know that I am the one who allows the sky to be blue? –  ThomasX Oct 4 '11 at 8:45

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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