"What is Technical Debt?"

THAT IS THE QUESTION... and you should know (!) the answer to this question in order TO BE AGILE. If not, now it is good moment to start finding more info on this subject.

Well... it is possible also to know the problem, but not with this formal name. 

Anyway, dealing with TD it is matter of TO BE OR NOT BE AGILE.  The full set of questions is:

• What is TD?
• How could be solved and/or managed?
• Do you use as a criteria for work assessment to have a low(enough) level of TD?

Just a hint: Scrum has the concept of "Done". In fact you are not really Done, if there is too much TD left behind at the end of Sprint work. That mean TD it is a matter of  "To be or not to be" also for Scrum adoption.

More: TD it is an "Elephant in the Room" for Agile, but also for Software Development as domain of activity (no matter the used process approach).

Scrum Guide changes - 2013 (comments)

Source

Original "Changes between 2011 and 2013 Scrum Guides" it is described by Ken Schwaber and Jeff Sutherland and could be found here:

https://www.scrum.org/Portals/0/Documents/Scrum%20Updates/Scrum%20Guide%202013%20%28Changes%29.pdf#zoom=100

Comments  - changes: step by step

Note: The comments are related to the 6 changes descriptions from the above document. 

 

1.  Artifact Transparency section

 

Scrum Artifacts are Product Backlog, Sprint Backlog, Product Increment - where the associated meaning could be Incoming Work, Work In Progress and Work Done. Indeed, the purpose of these artifacts is to offer a common view and transparency over the status of the work related to the product. Transparency of these documents (visibility etc.) it is fundamental in realization of the Scrum principle of Transparency. This guide change is an indication to be aware of this aspect.
 

2.  Sprint Planning - One event + Sprint Goal formal inclusion

"One event" - In fact what is changed is that the two goals of the Sprint Planning - define WHAT and define HOW - are no more formally split in 2 sub-events. That is an improvement, because splitting these aspects in 2 sequential events was artificial, because the real process it is logically iterative. 

Sprint Goal formal inclusion - this is an indication that Sprint Goal is fundamental for the Sprint: defining the Sprint has as a core aspect defining this goal.
 

3. "Grooming" changed to "Refined"

This change it is a major improvement in the Guide effectiveness. This aspect was already explained before by Jeff Sutherland, and now it is official in the guide.The purpose of  "grooming" (the previous name) it is now more clear. The goal is to bring the Product Backlog Items in the "Ready" state, before selecting them for development inside the Sprints. The term "Refined" indicate better that this should be a process having the final goal to reach this "Ready" state.

4. Scrum events durations rule change - avoid waste

The prescribed event duration is defined now as a maximum values for all events excepting the Sprint.  That clearly indicate that you can terminate early (if is possible) and avoid waste. 

5. Daily Scrum changes

The changes clearly indicate the Scrum Goal realization as main reference for this meeting. Also the 3 main questions from this meeting agenda has been changed accordingly.   

Anyway, in my opinion there is also an "downgrade", because "done" it was replaced with "do" in the questions. 

 

6. Sprint Review changes 

It is indicated more explicitly that end of the Sprint it is a moment of "Inspect and Adapt" for the product and project(s): stakeholders participation, review product and releases versus marketplace.

 

Comments  - A final view

These changes are not "extensions" of the Scrum, but rather improvements and clarifications in the direction of Scrum effectiveness in realization the Scrum principles : Transparency, Inspect and Adapt.