Let's say, you are a Scrum Master and your team is in the middle of a Sprint. You see that all planned stories can't be completed till the end of the Sprint, that's for sure. What action will you perform?
Tell me more
×
Project Management Stack Exchange is a question and answer site for
project managers. It's 100% free, no registration required.
|
|
It's wise not to interfere with the team inside sprint. Failure is healthier than a forced succes. Retrospective of a failed sprint is more interesting that a success sprint one. PO should be warned but only if he dosen't have authority and opportunity to put pressure on the team. For him/her, a planned failure it's way more better than an unexpected one, even more if is a outside company client involved. Make sure that information radiators are properly updated, and trust in your team until the last minute of the sprint! Any complains before the sprint ends may be seen like a lack of trust. When the fail it's declared stand by your team as it's your fail too. Don't look for guilty persons and don't let the team start this charade. Work hard with stakeholders to create a tolerance for failure. The team should be ashamed not afraid to fail. If you don't have any tolerance for failure your team will force success by eroding quality and adding technical debts. You don't want that. NEVER stop a sprint because it may fail. It will be a living proof that you don't trust your team, and you'll be screwed as a ScrumMaster. Learn to be patient. |
|||
|
|
If you're just talking about completing stories, I think you really only have two choices, alter the scope of the current stories or work more hours to finish the current stories. To get back to your question, if I were the Scrum Master of a team who found themselves in this situation I would ask them what they think should happen and help them discover a solution. |
|||
|
|
|
You have to either cut low priority stories or abort the sprint and start over. You could also continue to the end of the sprint which leaves you with low velocity for the next sprint. This would allow you to do a better job of estimation next time around. This is the point where many orgs simply abandon the core principles of scrum and start to add scrum-buts. |
|||||||||||||
|
|
Don't abort the sprint, because this will demotivate the team ("Oh, just another sprint we couldn't finish.")! Better: Inform the steakholders/POs about the situation and stories that might not be finished by the end of the current sprint. As you might have more than one story in a sprint and a given priority you should have at least a few other stories ready for release. Important: Address this topic during the retrospective at the end of the sprint. Why didn't we (as in team) manage the finish the sprint - i.e. finish all comitted stories? Did we have an impediment? Did we have technical blockers? Did we just underestimate a bigger story? If so, restimate this story and take this one as reference story for the next estimation meeeting. And last but not least: Learn to be patient - as Radu said in his very good answer. |
|||
|
|
|
During the teams stand-up when it becomes apparent that stories aren't going to be completed during the sprint I want to know:
I've found that adding a 4th question to a teams stand up can help with identify when a sprint is off track. It also increases the teams communication and raises awareness of the sprint commitment. Use this question alongside the standard SCRUM standup questions and in my opinion your one step closer to a more productive team:
|
|||
|
|
|
Immediately communicate up and down. Down (team members). Ask what the problem(s) are that lead to this - don't assume you know the full picture. Ask how these came up. Ask what solutions people would recommend. Would priority would developers put on items? Which ones 'could' they do given the circumstances. A lot of these skills will be leadership skills in how to listen to your team. Up (management). Tell management about this. Say this YOU made a mistake on the previous estimates (rather than 'explaining away with other 'reasons'). Ask management to look again at the priorities and determine which they want to do in the sprint given the circumstances. The 'up' and 'down' might be done together but that's really going to depend on a ton of disparate factors about both the organization, its structure and the people involved. Future. Try and make the take-away be that "things always happen" and, going forward, use this knowledge in future estimates to make them more realistic. Stuff ALWAYS 'comes up' and a good project manager accounts for this in time estimates. |
||||
|
|
|
I'd do nothing. Our sprints are one week long. At the end of the sprint and when we prepare the next one we reflect on the old sprint. In this case, as the team hasn't met the sprint objectives, it needs to learn from it and do a better job in the next time. As the team discusses the reasons for the failure, potentially moderated by a coach, they identify options for what they want to try out to do better next time. Over time the team will become better at achieving the sprint goals. Of course if your sprints are much longer you may decide to choose a different option. In my experience interfering with the current sprint is usually the worst option and I try to stay away from it. |
|||
|
|
Of course, the answer really depends if this is the team's first sprint, or fifteenth together. If it their first, then it is probably more important to learn and understand why. If it is the fifteenth, you may just need to help the teem prioritize and ensure the sprint activities are well prioritized |
|||
|
|
|
@Radu Impediment is poor nomenclature by me. Yes, meant for it to be solved at retrospective time. Apologies. Disagree with the rest of your post although it provides valuable insight and perspective on how some teams could react to scrum masters who do not "toe the line". The past 18 years of mine have been spent working for stock exchanges and investment banks globally and the delivery cadence demanded by that business context is much faster than that generally provided by Agile methods (2-4 week sprint). Add to that, the dynamic of traders whose persona "overnight is long term" and margin for error is not that high. My intersect with Agile is via Nonaka's SECI, Boyd's OODA and more recently Snowden's Cynefin and Ken's scrum. In my experience, most agile teams look at the practices as an end in itself without considering the dynamics of the business context and consequent impact on system design and service delivery design. This results in practicing agile without having the agile mindset and service orientation. As Kent Beck says, Agile is custom to the team that adopts it. Teams should understand that failure to sprint goals is not about Agile but about a negative business outcome. Providing them the opportunity to learn about it is really a result of prevalent culture (Hoffstede, Schein, etc) more than the Agile process per se. Yes agile provides a forum via the retrospective, but content and outcome therein is really about deeper underlying triggers. Understanding the theory behind the process ensures we do not blindly apply what agile books tell us... i.e. without considering context. |
|||||
|
|
Raise an impediment for the team to problem solve on how would they handle this risk to business outcome, their credibility and planning depth. |
|||
|
|
