Posted on

Liberating Structures and (distributed) Scrum Events

For an upcoming meetup I’m preparing a session on how to use LS for Scrum Events and especially events where the participants are distributed and joining the event remotely.

Here’s a brief overview of some LS that can be used for the different Scrum events. I’ve marked all structures with an * that I’ve used myself in a distributed setting.

Refinement / Planning

Daily Scrum

Sprint Review

Sprint Retrospective

On the liberating Structures website you can find a design checklist for virtual meetings. Since the link is currently no longer working, you can find the document here:

DESIGN of LIBERATEDVIRTUALMEETINGS v2Download

Posted on

How to: A Great Product Backlog Refinement Workshop

To conduct the workshop, follow these steps:

  • In 30-minute cycles,
    • The PO presents the next PBIs that aren’t Ready to the team. (up to 5 minutes)
    • The Development Team decomposes into sub-teams of 3-4 people.
    • Each sub-team selects one of the next PBIs and gets it Ready. (15-20 minutes)
      • Use User Stories, 3 Cs, INVEST, your Definition of Ready, etc. to guide you.
      • If Readiness is blocked by an impediment outside the Scrum team, the sub-team makes a concrete plan for what they will do to get the PBI Ready before the next Sprint Planning or Backlog Refinement meeting.
    • Merge back into whole group, the full Scrum team.
    • Sub-teams present their work to the whole group. (5-10 minutes)
    • Take a break (5 minutes)
    • Repeat
  • Celebrate!

Read the original article here: https://kasperowski.com/how-to-a-great-product-backlog-refinement-workshop/

Posted on

28 Product Backlog and Refinement Anti-Patterns

Scrum is a practical framework to build products, provided you identify in advance what to build. But even after a successful product discovery phase, you may struggle to make the right thing in the right way if your product backlog is not up to the job. Garbage in, garbage out – as the saying goes. The following article points at 28 of the most common product backlog anti-patterns – including the product backlog refinement process – that limit your Scrum team’s success.

Read the complete article here: https://age-of-product.com/28-product-backlog-anti-patterns/

Product Backlog Anti-Patterns
Posted on

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

Posted on

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

Posted on

Why Agile Teams Should Estimate at Two Different Levels

It is very common for agile teams, especially Scrum teams, to estimate both their product backlog and sprint backlogs. In this article, Mike Cohn will address:

  • Why estimating both the product backlog and sprint backlog can be useful even though it seems redundant
  • Why teams should estimate the two backlogs in different units
  • When teams should estimate
  • Whether all teams should estimate

Although I think you should not try to use hours for estimation, I agree using different valuations for an estimation is best. I find using T-shirt sizes for PBIs and Story Points for SBIs work well.

Read the complete article here, and also take note of some excellent comments at the bottom: https://www.mountaingoatsoftware.com/blog/why-agile-teams-should-estimate-at-two-different-levels