Updated: Aug 13, 2019
Last Tuesday I provided you with three more challenging Scrum Mastery questions. As promised I'm updating the quiz with the correct answers, along with an explanation. I've bolded the correct answers in blue. I will be posting quiz #3 tomorrow.
Thank you to all who felt courageous enough to add your answers in the comment section of the blog. So how did you do?
Your Scrum Team has taken over the ongoing support and enhancements of a software product developed by a third party company, which was turned over to your Scrum Team 6 weeks ago. After three Sprints of working on new enhancements, the Development Team has discovered a large amount of technical debt, which is making it a challenge to complete a “Done” Increment each Sprint. What is the best option going forward?
Since Product Owners have no accountability for technical debt, the Development Team should keep a list of all technical debt in their own special Development Backlog, and every Sprint they should work to clean up the technical debt and make that work transparent in the Sprint Backlog.
The Development Team should collaborate with the Product Owner to make all of the technical debt transparent on the Product Backlog. The Scrum Team should also form a working agreement to focus a small amount of their capacity each Sprint to remove and repay technical debt, until the Scrum Team agrees it is under control.
The Product Owner should stop all new product enhancements immediately after the current Sprint. The lead developer should work with the Product Owner to quantify and set priority on the technical debt. The Development Team should then remove all of the technical debt in hardening Sprints, before proceeding with any new enhancements.
The Scrum Master should break the Development Team into two teams. The Scrum Master should then assign one Development Team to focus on technical debt, and have the other Development Team focus on working with the Product Owner to build new enhancements.
Correct Answer: 2. Technical Debt should be made transparent in the Product Backlog, and the Scrum Team should focus on paying down a small amount of it every Sprint. Having a working agreement with the Product Owner is important, since they are accountable for the Product Backlog.
Incorrect Answers: 1 is incorrect because the Product Owner is accountable for the total cost of ownership of the product (including the cost of technical debt), and the work should be added to the Product. 3 is incorrect because there is no such thing as a ‘hardening Sprint’. 4 is incorrect because the Development Team should be the ones to self organize into two teams, there are no roles such as lead developers on the Development Team, and and the Scrum Master does not assign work.
Which of the following may be inputs into Sprint Planning? Select all vapid answers that apply.
Past performance of Development Team (e.g. velocity, throughput)
Projected Capacity of Development Team for current Sprint
Definition of "Done"
Definition of "Ready"
All of the above
Correct Answer: 1, 2, 3, 4 and 6. 1. Makes sense because Product Backlog items get selected for the Sprint Backlog. 2 is correct because past performance is empirical data that could help the Development Team in forecasting the amount of work for the Sprint. Velocity is one measure, but throughput or other ways could be used. 3 is correct because the team should understand the state of the Increment, are if there are quality issues or technical debt that may need to be discussed. And of course 6, the definition of "Done" can guide the team when deciding how much Product Backlog to select for the current Sprint.
Incorrect Answers: 5. Sprint Goal is not an input into Sprint Planning, it is created during Sprint Planning to guide the team, and is an output of Sprint Planning. 7. Definition of "Ready" isn't actually part of Scrum. Scrum only says "Product Backlog items that can be "Done" by the Development Team within one Sprint are deemed "Ready" for selection in a Sprint Planning."
The Scrum Team has had a challenging Sprint, and will not be able to meet their Sprint Goal. Two members were unexpectedly out sick, the Product Owner was in training for the last 3 days of the Sprint and has not been able to provide feedback, and test environments were down for a good portion of the Sprint, hence the Development Team could not finish a lot of testing. The day before the Sprint Review and Sprint Retrospective, the Development Team pushes hard to cancel these two events. As Scrum Master what do you do? Pick the best answers.
Since only a Product Owner may cancel a Sprint Review, work with her to cancel the Sprint to avoid wasting the stakeholders time.
Suggest the Sprint be extended by two or three days to give the Development Team time to finish testing and to get feedback from the Product Owner,
Cancel the Sprint Review because there isn't anything to demo, but keep the Sprint Retrospective because there are some important topics to discuss and improve upon next Sprint.
Uphold Scrum by not cancelling these events, and help the Development Team understand the benefits of being transparent and for the need to collaborate with stakeholders on the upcoming Sprint. Help the developers understand that the Sprint Retrospective is needed to inspect what happened and to improve next Sprint.
Correct Answer: 4. The Scrum Master upholds Scrum, not by being the Scrum police and stating "because the Scrum Guide says so", but by helping the Development Team get to the "why" behind the event. Although things didn't go well, it is important to meet with the stakeholders at the Sprint Review to be transparent on the challenges faced, and also to adapt the Product Backlog collaboratively for next Sprint, as conditions may have changed since last Sprint. And since there were many challenges, the Sprint Retrospective is even more important to inspect and adapt for next Sprint.
Incorrect Answers: 1 is incorrect. While it is true that only a Product Owner can cancel a Sprint, cancelling the events are not the right answer. 2 is incorrect because extending a Sprint goes against the concept of time-boxing. The Development Team needs to work on a cadence to learn how to deliver a "Done" Increment with a rhythm. And besides there is no evidence that extending the Sprint would work. 3 is not the best answer. While keeping the Sprint Retrospective is great, the Sprint Retrospective needs to happen as well for the reasons listed above.