@billseitz @bernie @anil Ok. Background check the three of us help organizations with Scrum, Kanban, DevOps etc.

FWIW I know and love (platonic) Ron. I've read that post, many times. One could argue our 3% Better Approach is an antidote to Ron's point.

I'm open to another another angle. Should I write about #ProductBacklogRefinement for Kanban? How does it differ from Scrum land?

Their item still spent a long time sitting in a queue and it doesn't matter what the queue was.

What other tips would you offer? (Fair warning, I will tell the world).

#EffectiveMeetings I'm slowly looking to every single detail I can find on #ProductBacklogRefinement

A ThreePercentBetter Production In partnership with @bernie and @anil

3/3 Bad Estimate

Another reason to dislike Ready, it encourages a local optimization. It makes the Scrum Team look good, by improving their cycle time, without necessarily improving things for the client. Example a Definition of Ready holds up a feature for 4+ weeks will requirements are being gathered. Now the Scrum Team looks good when they work on the item their cycle time will be low. However the customer isn't any happier.

2/3 :-) #ProductBacklogRefinement #EffectiveMeetings

#DefinitionOfReady
Under some circumstances a Definition of Ready helps a Scrum (or Kanban Team) ensure their Product Backlog Items are well thought out. This means nothing is consider for Sprint work that would get probably get stuck.

I've already pointed out that ready encourages mini-waterfall/gate system.

1/2 #ProductBacklogRefinement #EffectiveMeetings

@sysop408 @bernie @anil Sheldon thanks. Mastodon limits context. #ProductBacklogRefinement is the activity in Scrum (and I guess Kanban) where the team and the Product Owner review the items that are coming up in the near term to make sure that there is a common understanding of what they want to build. This article is good starting point: https://resources.scrumalliance.org/Article/product-backlog-refinement

Pivot in Public. Nearly a month of writing about #ProductBacklogRefinement I'm seeing little engagement. As a student of #LeanStartup I want to learn from my audience.

Write in candidates are also appreciated.

A ThreePercentBetter production in partnership with @bernie and @anil
#EffectiveMeetings #BuildInPublic #Pivot

Help me understand:

This set of tips summarized from https://www.shortcut.com/blog/how-to-do-backlog-refinement-less-wrong

What other tips would you offer? (Fair warning, I will tell the world).

#EffectiveMeetings I'm slowly looking to every single detail I can find on #ProductBacklogRefinement

In partnership with @bernie and @anil

- Collaboration should involve hearing from all voices, a good ScrumMaster should be facilitating to give everyone an opportunity to share
- Don’t get too far ahead - 3ish Sprints of well understood work is enough. (Some will argue even less is better)
- You don’t need to detail each and every acceptance criteria in Backlog Refinement

What other tips would you offer? (Fair warning, I will tell the world).

3/4 #EffectiveMeetings #ProductBacklogRefinement

- Everyone has a different definition of ready. (Hint I warned that Ready has some risks)
- Product Backlog is being refined 6+ Sprints out - too much detail too far ahead team members feel their time is being wasted.

The Cure (cue 80’s music)
- PO preps before refinement - they deeply understand what they want worked on, they know who needs to be there and as others have suggested they might even tell people in advance what will be worked on

2/4 #EffectiveMeetings #ProductBacklogRefinement

I love the title Less Wrong Backlog Refinement. This article pleasantly surprised me. This is a tool vendor site (it’s goal is to be a better than JIRA Scrum/Kanban tool), most tools vendors do not understand Scrum.

They open with Anti-Patterns:
- Meeting is used to assign work
- Team Member My opinion doesn’t matter, often because the PO is telling, not listening
- PO is Micromanaging or it’s opposite absent
- PO is unprepared

1/4 #EffectiveMeetings #ProductBacklogRefinement

Excellent. If it becomes cumbersome, making it difficult for the PO, maybe it’s too much.

FWIW I’m not linking to the article because I realize that most the rest of the article is just summarizing other sources already mentioned.

What other tips would you offer? (Fair warning, I will tell the world).

#EffectiveMeetings I'm slowly looking to every single detail I can find on #ProductBacklogRefinement

In partnership with @bernie and @anil

I’ve seen Definition of Ready go off the rails when it becomes a long list and returns us to waterfall style gate system: Product Backlog -> Definition of Ready -> Sprint Backlog -> In Progress -> Definition of Done. The two “Definitions” one formally part of Scrum, one informal become the traditional phase gates.

If your Definition of Ready is short and to the point, it maybe helping clarify the work.

2/3 🙂 #EffectiveMeetings #ProductBacklogRefinement

An article I read tells a story of team struggling during their Sprint suffering from mini waterfalls because their Product Backlog Items were ill defined. (A sad oft heard tale). So they set about curing the problem. Just be aware that the cure, Definition of Ready, can become part of the problem at a later date. In this case the Definition of Ready: Clear, Small and Testable; feels like a restatement of INVEST (which the author also mentions).

1/3? #EffectiveMeetings #ProductBacklogRefinement

If there was any single blog in this series (aside from my own :-) that I might suggest you follow it is The Liberators. Too bad Medium makes it impossible to get an RSS feed.

What other tips would you offer? (Fair warning, if I agree I will tell the world).

#EffectiveMeetings I'm slowly looking to every single detail I can find on #ProductBacklogRefinement. Needless to say most of them had no useful tips. In partnership with @bernie and @anil

4/4

Backlog Refinement can prevent Zombie Scrum - I love the phrase Zombie Scrum. It conjures to mind teams using the practices of Scrum and getting limited benefit. They ran a workshop with their subscribers to find what was helping them with #ProductBacklogRefinement

The tips:
- Vote on which item(s) in the PB are least clear
- Invite Stakeholders to the refinement session - in particular stakeholders who have PBIs that are near the top of the Product Backlog

1/4 #EffectiveMeetings

For me the deeper thought is if you hit violate the limits often or feel the urge to re-estimate in Sprint Planning, it’s probably a sign. Consider a deeper discussion in a Retrospective. (consider NoEstimates).

Not linking to the original post b/c I’m not trying to pick a fight with the author. I might differ with some suggestions not the person.

#EffectiveMeetings I'm slowly looking to every single detail I can find on #ProductBacklogRefinement. In partnership with @bernie and @anil

...
If the tradeoff is an extra 1-2 mins vs risking losing a team member’s voice, I will add the time.

Finally, there is a suggestion that estimation can happen in Refinement (yes) -> Sprint Planning (seems late) -> Start of work on the PBI (just ugh).

The win they cut down on the time spent in Backlog Refinement and mostly good. I like the idea. Timeboxes often help.

#EffectiveMeetings #ProductBacklogRefinement

3/5 - a bad guess

...
Halt. Cue the irony. Planning poker was invented to solve the very problem the author was having. Fast forward 20 yrs and the problem pops back up. I think it’s a hydra.
-
Most planning poker rounds, whether Story Point, T-Shirt sizing or gummy bears should resolve themselves after 3 rounds. The majority rules adopted by the author increases the likelihood that outliers and/or quieter team members will feel silenced.

#EffectiveMeetings #ProductBacklogRefinement

2/5 - a bad guess

4-minute refinement rounds?

Refinement was taking so long even after two time slots in a Sprint, the team still wasn’t ready for the next Sprint. The author’s change was to limit refinement on any item to four mins.
1st min - PO gives a quick recap
2nd min - Team questions
3rd min - Planning Poker round to find outliers, who explain thinking
4th min - Planning Poker again majority rules.

#EffectiveMeetings #ProductBacklogRefinement

1/5 - a bad guess

We’ve shared over 20 articles on effective backlog refinement over the past two weeks. Key question:

Are there gem articles from individuals (seriously we promote small people not corp SEO teams) that we missed?

#EffectiveMeetings I reviewed 168 sources on #ProductBacklogRefinement so you wouldn't need to. Needless to say most of them had no useful tips. In partnership with @bernie and @anil