Author: jcdejong

Posted on

The (surprising) 9 most common challenges that Product Owners face, and affect their Scrum Teams

  1. The PO doesn’t have enough time
  2. The PO doesn’t have the right skills and I’m expected to train him/her
  3. The PO can’t create a Release plan (or other critical artifacts for that role, like Vision or Product Backlog)
  4. The PO does not engage with the team and ends up working alone
  5. The team suffers from slow feedback and the PO doesn’t get the feedback they need either
  6. The PO does not feel empowered to make decisions
  7. The PO serves many teams and/or has many roles
  8. The PO is a micro-manager and wants to control everything that happens
  9. The PO needs to serve and align with too many stakeholders

Read the complete post and listen to the Scrum Master Toolbox Podcast here: https://scrum-master-toolbox.org/2018/11/blog/the-surprising-9-most-common-challenges-that-product-owners-face-and-affect-their-scrum-teams/

Posted on

Six Guidelines for Saying No to a Stakeholder

Saying no can be very difficult. Most of us like to please others. But when we say no, we disappoint the requester.

Here are six guidelines for saying no to a stakeholder by Mike Cohn:

  1. Be Clear with Stakeholders: Is this No? Or No, for Now?
  2. Express Appreciation and Empathy for Customers
  3. Offer Only One Reason for Saying No
  4. Convey that You Each Have the Same Goal
  5. Explain the Consequences of Saying Yes to the Stakeholder
  6. Offer the Customer an Alternative

Read the complete article here: https://www.mountaingoatsoftware.com/blog/six-guidelines-for-saying-no-to-a-stakeholder

Posted on

Ten sentences with all the Scrum Master advice you’ll ever need

Mike Cohn has been a Scrum Master for over 20 years. Over that time, he gave and collected quite a lot of advice and distilled it down to the ten best bits for you:

  1. Never Commit the Team to Anything Without Consulting Them First
  2. Remember You’re There to Help The Team Look Good
  3. Don’t Beat the Team over the Head with an Agile Rule Book
  4. Nothing Is Permanent So Experiment with Your Process
  5. Ensure Team Members and Stakeholders View Each Other as Peers
  6. Protect the Team, Including in More Ways than You May Think
  7. Banish Failure from Your Vocabulary
  8. Praise Often But Always Sincerely
  9. Encourage the Team to Take Over Your Job
  10. Shut Up and Listen

Read the complete article here: https://www.mountaingoatsoftware.com/blog/ten-sentences-with-all-the-scrum-master-advice-youll-ever-need

Posted on

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

Cheatsheet-10-Strategies-to-Break-Product-Backlog-ItemsDownload
Posted on

How writing Unit Tests forces you to write Good Code: And 7 bad arguments why you shouldn’t

Unit Testing is about writing good, well-designed, decoupled code that, as a result, is automatically testable.

Good Code is code that works well and is easy to maintain, extend, comprehend and understand (in the present and in the future).

The following (well-established) practices are important:

  • Reduce coupling
  • Maximize encapsulation
  • Single responsibilities
  • DRY
  • Open/closed
  • Documentation
  • Use design patterns

What is a Good Unit Test?

  • Tests only your class, not it’s depedancies
  • Input/output checks
  • Hypothesis-based
  • Concept-based
  • Small
  • Intuitive
  • Uses business/domain terminology

Reasons why you should not write a unit test:

  • ‘Unit testing takes too much time or is too difficult’
  • ‘Unit testing is a luxury (we don’t have)’
  • ‘Unit testing is not necessary, because I already write Good Code’
  • ‘Unit testing is not possible with this legacy code’
  • ‘I don’t have enough knowledge of Unit Testing’
  • ‘Unit testing are inferior to regression/integration/manual tests’
  • ‘Someone else (like a tester) can write tests for my code’

Read the complete article here: https://medium.com/the-liberators/how-writing-unit-tests-forces-you-to-write-good-code-and-7-bad-arguments-why-you-shouldnt-9b0cc3461d7a