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
  • 2
  • 8
  • 7
    Ironically, this is where such a stringent compliance with agile results in too much rigidity. Step back a sec from the fact that you're trying to adjust an agile approach. Somebody's left your team, redistribute the work load and prioritise. You don't need an agile-specific answer here. People take these methodologies too literally. Without sounding patronising, it's nothing but common-sense what you must do here. – JᴀʏMᴇᴇ May 23 '16 at 09:03
  • As a coach, I always tell my team: DO WHAT MAKES SENSE! What do the PO and stakeholders need to hear? What decisions do they need to make? What impacts does this departure have on the team for the short, mid and long term? What needs to be done to fix that? Thankfully, Scrum and Agile are based off Values and Principles and NOT a dense book of rules. – Curtis Reed Feb 28 '18 at 16:56

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,326
  • 19
  • 166
  • 181
  • 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 04 '11 at 06: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 04 '11 at 07:46
  • Is that mean I have to start a sprint planning session again? Sprint planning session seems quite involving. – janetsmith Oct 04 '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 04 '11 at 18:56
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,387
  • 14
  • 137
  • 224
  • 2
    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
  • 2
    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
  • 4
    @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 01 '11 at 01:22
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
  • 6
  • 8
Ladislav Mrnka
  • 7,326
  • 1
  • 23
  • 32
-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
  • 338
  • 2
  • 8
  • 1
    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 04 '11 at 08:45
-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