A life committed to learning.

Scrum Quick Qizz

You’re the ScrumMaster for organization Foo and you’re working with  Team Bar. In the first sprint planning meeting you’re thinking that the team committed too much functionality from Product Backlog. You, the ScrumMaster, reminded the team that they are responsible for  committing only functionality that they can complete in a Sprint, and they can drop any functionality that they feel that cannot be completed.

The Team Bar strong believed that they can do so much work. They proceed with the Sprint.

At the sprint review meeting, the team demonstrated the functionality committed. The demo was guided by a script that team members follow consistently and religiously. Stakeholders at the meeting congratulated the team for the work done. At the end of the of the sprint review meeting, you started to play with the functionality delivered by the team and ignored the script they used to try different use cases. The software started to throw exceptions and crashing.

What went wrong?

A) The time spent in Spring Planning Meeting wasn’t enough.

B) The time allotted  for Spring Review Meeting wasn’t enough.

C) Team Bar ignored the rule of Sashimi.

D) Everything went ok. What’s the point?

What is you best guess? Why?



View more posts from this author
One thought on “Scrum Quick Qizz
  1. Jorge Alves

    Team Bar doesn't know what “done” means. The use cases you mention shouldn't even be availble if they're part of stories in the backlog, or they should work properly if they were supposed to be done already.

    What went wrong? My guess is that the team focused on implementing the functionality in order to make everyone happy and passing the “test” of review. In other words, they're not being agile. They're just following the path of least resistance for the process implemented.

    I sense a death march coming in for this team 🙂


Leave a Reply

Your email address will not be published. Required fields are marked *