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:

Enhancing Sprint Review With The Speed Boat Game

The Speed Boat game explores user’s pains and jobs. The heart of the game is a metaphor of a Speed Boat (product). It has anchors: current problems and pains in using the Product that prevents it from moving forward. The stronger the anchor, the higher amount of customer pain, the more anchor slows the boat down.

Read all about it here:

Retroformat for teams that have not yet experienced a useful learning retrospective

Team identifies things that help, but the can’t control. “Thank the org” – let them know to continue these things!

Things they can’t control and hold them back… Escalate. Inform mgmt, coaches, etc.

How to facilitate this:

Found this information on Twitter:

The difference between the ‘forecast’ and the ‘Sprint Backlog’ in Scrum

There is a difference between the forecast and the Sprint Backlog in Scrum. Exactly what this difference is, has eluded me for some time, and it may very well be unclear to you too. The difference may seem subtle but can have real practical benefits as you will learn below.

Continue reading here:

How to Lead Change Management – A Systemic Approach

Any time leaders try to introduce change into an organization they will be faced with the fear and conflicts of the people involved in the changes. Dealing with these reactions is one of the most delicate, intangible and crucial aspects of leading change management. How can we do that in a systematic and constructive way? Dr. Goldratt was able to identify six levels (or layers) of resistance to change.

  • Level 1: Disagreement about the problem
  • Level 2: Disagreement about the direction of the solution
  • Level 3: Lack of agreement that the solution will bring the expected benefits
  • Level 4: Fear of negative consequences generated by the solution
  • Level 5: Too many obstacles along the road that leads to change
  • Level 6: Not knowing what to do

Read the complete article here:

Getting Results from Sprint Reviews

Some insights of this video include:

  • What could the agenda of a sprint review look like?
    • Show the (big picture) vision of the product
    • What was the sprint goal (vision of the previous sprint)
    • Discussing the sprint itself
      • what went wrong
      • what problems did we run into?
      • how did we solve these problems?
      • what still needs to be solved?
    • Review the increment (not really a demonstration, but an actual review)
    • Now that you’ve seen it, do we need to change anything?
    • Project likely completion dates
    • Collaborate/discuss what should be built next?
      • What is the marketplace we are operating in?
      • What are our competitors doing?
    • Final question: should we change the Product Backlog, should we change?