Myth: Refinement is a required meeting for the entire Scrum Team

In this post, The Liberators bust the myth that Product Backlog refinement should be done as one or more required ‘meetings’ that must be attended by everyone in the team. They clarified the purpose of refinement in Scrum, offered alternative approaches to do refinement and provided some tips to increase the effectiveness.

Read the complete post here: https://medium.com/the-liberators/myth-refinement-is-a-required-meeting-for-the-entire-scrum-team-b17fb7bc25fa?mc_cid=d2843cbf59&mc_eid=b8b1840566

Product Backlog Refinement is a Scrum Team Responsibility

This article on Product Backlog refinement shows that Refinement is more than just a meeting where the whole Scrum Team is having a discussion. It requires and involves everyone with shared and special responsibilities. It’s easy to lose sight of the importance of Product Backlog refinement because of your focus on the Sprint. But making time for healthy Product Backlog Refinement makes way for an awesome collaboration and teamwork, building a product that customers really enjoy!

Read the complete article from Jasper Alblas here: https://www.scrum.org/resources/blog/scrum-trenches-product-backlog-refinement-scrum-team-responsibility

10 powerful strategies for breaking down Product Backlog Items in Scrum

Teams that have mastered Scrum know that the key to success lies in a just-in-time, increasingly refined, breakdown of work on the Product Backlog. They prefer Sprint Backlogs with many small (functional) items instead of just a few large ones. Smaller items improve flow and reduce the risk of failing the sprint. In this article, I will explain why the breakdown of work is important, and why it should be done across functional — instead of technical — boundaries. Christiaan Verwijs offers 10 useful strategies that experienced Scrum Teams use to break down work in this article: https://medium.com/the-liberators/10-powerful-strategies-for-breaking-down-user-stories-in-scrum-with-cheatsheet-2cd9aae7d0eb

Road to PSMIII

Sjoerd Nijland has written a nice series of blogposts about his road to PSMIII:

Definition of Scrum
https://medium.com/serious-scrum/definition-of-scrum-2d1f224256c

Empiricism: Transparency
https://medium.com/serious-scrum/empiricism-transparency-33adad8fbba2

Empiricism: Inspection, Part One
https://medium.com/serious-scrum/empiricism-inspection-part-one-cc4cd8bf98a8

Empiricism: Inspection, Part Two
https://medium.com/serious-scrum/empiricism-inspection-part-two-fafb785bd0c0

Empiricism: Adaptation
https://medium.com/serious-scrum/empiricism-adaptation-975f044a09b2

Scrum Values
https://medium.com/serious-scrum/scrum-values-1203813e0220

The Scrum Team
https://medium.com/serious-scrum/the-scrum-team-75b8004a4bc2

The Scrum Master
https://medium.com/serious-scrum/the-scrum-master-729e223f4b64

The Scrum Master’s responsibilities
https://medium.com/serious-scrum/the-scrum-masters-responsibilities-7ee05cae707e

The Product Owner
https://medium.com/serious-scrum/the-product-owner-6b7a63fef8fe

The Development Team
https://medium.com/serious-scrum/the-development-team-575d69054a9b

The Sprint
https://medium.com/serious-scrum/the-sprint-40d0ccc895f9

Sprint Cancellation
https://medium.com/serious-scrum/sprint-cancellation-c9a9c66e8c99

Scrum’s Artifacts
https://medium.com/serious-scrum/scrums-artifacts-6f07abfab11

The Product Backlog
https://medium.com/serious-scrum/the-product-backlog-7aec7daf844f

Estimation
https://medium.com/serious-scrum/estimation-103de626551e

Asking the right questions; how to help a Scrum Team switch from a technical to a functional Backlog

One of the biggest challenges for a Scrum Team is to switch from a technical to a functional perspective on their work. Christiaan Verwijs has developed a set of helpful questions that often trigger teams into a functional frame of mind.

  • Why is it important that we implement this?
  • What problem of stakeholders and/or end-users do we solve by doing this?
  • What personas benefit from this, and why? (given that you have personas)
  • How would sales explain the benefits of this to customers and/or users
  • What reasons would an end-user have to want this?
  • How would you explain this to a colleague who is not part of this project?
  • How would you explain this to your spouse, at home, after a hard of work?
  • What would you show during the review to demonstrate that this is working?
  • If you are a user, how would you test if this works?
  • What changes would a user notice after implementing this?
  • What stakeholders benefit from this, and why?
  • If we wouldn’t do this, what would end-users and or customers miss or be unable to do?
  • What compliment would a happy user of customer give after delivering this?
  • How would you explain this to a potential end-user?
  • What steps would you go through in the application to test if this works?
  • If we’d put this in release notes that will be read by end-users, how would we announce it?

Read the original article here: https://medium.com/the-liberators/asking-the-right-questions-how-to-help-a-scrum-team-switch-from-a-technical-to-a-functional-bee6c1598487