12

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

janetsmith
  • 183

5 Answers5

20

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.

Oded
  • 53,734
2
  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.

pdr
  • 53,768
0

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.

John Gaines Jr.
  • 1,116
Ladislav Mrnka
  • 7,356
-1

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.

tylermac
  • 348
-2

Analyse the impact on overall sprint. Identify alternative solution/ work around. Discuss with product owner to move less priority/important user stories to next sprint. Bring in additional resources for this sprint or future sprint.

Pani
  • 1