Professional Scrum Training Courses
Professional Scrum Competencies
Scrum.org has created these Professional Scrum™ Competencies to help guide an individual’s personal development as they learn Scrum.
New and Now at Scrum.org
Professional Scrum Product Owner - Advanced Training Course
Advanced Scrum Master course designed to support experienced Scrum Masters in their professional journeys.
Updated Professional Scrum Product Owner Certification Assessment Levels
Comprehensive series of Professional Scrum Product Owner (PSPO) certification assessments with fundamental, advanced and distinguished levels.
Mastering Professional Scrum
A Practitioner s Guide to Overcoming Challenges and Maximizing the Benefits of Agility
Agile Leadership Toolkit Book
Learning to Thrive with Self-Managing Teams
Professional Scrum Certification Assessments
New Blog Posts
Should the PO really balance the level of technical debt? I just had this conversation yesterday at Sweden's "big" agile conference, Agila Sverige. There were many interpretations, understandings and strategies around this. I think it mostly boiled down to these two ways of looking at and arguing around it: On one hand: what is different about technical health/debt, than say features targeting a key stakeholder's user base? Isn't tech debt/health just one aspect of the product, coming from one stakeholder (Development Team in the tech case), that the PO needs to balance with other aspects? On the other hand - the Development Team is accountable to the (technical) quality of the increment (and thus the product), and continual refactoring is something they perform on a daily basis, as needed, to keep the product's tech health in check. Two Cases, Two Sizes In the conversation that was had, this more or less boiled down to two cases: A) the work that needs to be done, is such a big change that it may not be completed in a Sprint and/or will require a major effort from the team. Risk and Cost is "real" and is considered to be on a level where the PO should at least be informed. I.e., this work needs to be challenged by other work and decided upon, at least in part, by the PO when the right time to do this work, is. B) the work to carry out is not of the size above, and thus is just part of Dev Teams daily work and accountability. Development Teams not spending enough time doing B type of work, might more often end up with A types of work, requiring them to more often argue/explain/motivate why that work is important to the PO. This is not the only way to end up with A type of technical rework, but not paying enough attention to technical soundness, coupling and cohesion, etc, may very well be a source of this type of work. I also argued, that If this happens a lot/often, the Scrum Master should perhaps pick this up (that A happens a lot), and help the team assess whether they're spending enough effort on design and implementation strategy. Tech Debt Inventory List So what about assembling some of those B-sized things in a list, so we don't loose track of them? Isn't this a violation of the idea the the Product Backlog is the only source of work? Again, I'd like to argue both ways: Yes, if this list starts to grow, such that it regularly accumulates into A-sized work, then this may become a problem. No, this is not a Product Backlog where the value of items needs to be weighed against each other by the PO. This is just a small reminder of things we should fix in the short term as we conduct our regular development of selected PBIs. This is similar to working with a test backlog (as described by Kent Beck in Test-Driven Development) - it's just a way to help the Dev Team stay focused and do their normal work in the Sprint. Final Words Scrum is a small framework. The world is big, and there's no way one size fits all. So - as with everything Scrum, empiricism wins: try one way of doing it, reflect upon it and then keep as is or try something different: inspect and adapt. Other Resources In a fairly recent Scrum Pulse, Mark Noneman talks more broadly about Dealing with Technical Debt - what it is, where it comes from and ways to live with and adress it.
Jan 18, 2020 Read blog
The topic of my blog today is another one that is common on client’s sites. The use of the terms Showcase, Show & Tell or Sprint Review. In this situation, there is likely to be a broad mix of people fulfilling the Scrum Master roles.
Jan 17, 2020 Read blog
Hi awesome people. Courage is one of the Scrum values and as part of my New Year's resolution this year I would like to have more courage to point out elephant in the room at the risk people may dislike me for doing it.
Jan 16, 2020 Read blog