Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
We have all been there: you’re deep into code and find a bug that has not been noticed before, or some code that should be cleaned up. You are right there so why not fix it? Sometimes the answer is yes, it makes sense to fix it then, following the old backpacker’s mantra of leaving things better than you found them. But other times the answer is no. How do you decide?
Here are some questions to ask. To proceed, the answer to each must be favorable.
While the new Scrum Guide is less prescriptive and more inclusive, it also ties up loose ends by including elements better, namely the previously free-floating Sprint Goal and the Definition of Done with the creation of Scrum commitments. This inclusion works remarkably well in the former’s case; regarding the latter, we need a shoehorn, though.
Foremost, the new Scrum Guide is less prescriptive, eliminating many suggestions such as the Daily Scrum questions, the need for at least one mandatory action item from the Retrospective becoming a part of the Sprint Backlog, or the advice on why Sprint cancelations are rare events.
"The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog" (quote from the Scrum Guide).
The Sprint Goal is a phrase that can be used in many different ways:
