My notes from conference sessions I have attended.

View the Project on GitHub jonfazzaro/conferences

Agile Virtual Summit [Bite Size!]

March 31st, 2021

How Healthy Conflict Goes Wrong

with Tricia Broderick

Cooperation: “I’ll help, as long as my work still gets done.”

Collaboration: “This is our work.”

Conflict is necessary for a team’s wisdom to emerge.

Don’t try to remove conflict from work, try to remove drama from conflict.

Karpman’s Drama Triangle

Rescuer creates Victim creates Persecutor.

Resolve drama by shifting the roles:

Rescuer to Coach.
Victim to Creator.
Persecutor to Challenger.

Stop trying to fix the people

And reveal the problem in the system.


Think Again by Adam Grant

Agile Planning with the Product Goal

with Dave Prior

The Product Goal is part of the Product Backlog. But it also describes the Product Backlog. How can you have something that describes the thing that it’s also a part of?

Vision is no longer mentioned in the Scrum Guide. Does Product Goal replace Vision? No.

A Product Goal has four attributes

  1. Strategic
  2. Focused
  3. Empirical
  4. Measurable

It’s useful

The Product Goal makes it easier to find a Sprint Goal: “what is something we can do in two weeks that moves us toward our Product Goal?”

The Product Goal is a velvet rope that keeps the riffraff out. (Although, people lined up outside the club are still eventually a concern of the club owners.)

Multiple Product Goals?

If you do identify multiple Product Goals at a time, should you have a backlog of Product Goals while focusing on one at a time? Lean thinkers would say no to this–focus on one, throw the rest away. They’ll either become obsolete while working on the first one, or they’ll come back up because they are still important.

“Let Scrum be a framework”

Meaning, don’t look to it for all the answers. It’s not desgined to be changed, but it is designed to be added to. The best way to do this will emerge for your organization.

The Product Goal changes what a Product Backlog is.

Before the goal to focus it, the Product Backlog was the container for everything–all of the ideas for the future of the product. In practical application, though, this quickly becomes a dumping ground, a catch-all for things the Product Owner couldn’t quite figure out how to say “no” to.

But with the Product Goal, the Product Backlog is an opinionated description of the future of the product. Items that don’t pertain to the goal can be readily dismissed, resulting in a cleaner, more valuable Product Backlog.

Q + A

“The team should agree on a safeword with management”

“Scrum makes the broken surface really fast.” When coaching, instead of “here’s how to fix this for better Scrum”, point out how Scrum has revealed an obstacle to your team/org’s goals.

Re-evaulate the Product Goal every sprint. Re-evaluate the Vision every quarter.

Product Goal vs. Epic? An epic is smaller, but also larger than a Sprint Goal.


Product Goal Canvas (Ralph Jocham)

The Top 5 Backlog Refinement Mistakes Almost Everyone Makes

with Richard Lawrence

How much refinement?

“Enough to start work, but not enough to finish work without more collaboration.”

1. Details too early or too late

Too early leads to waste and rework. Too late leads to scrambling and dependency delays.

Items should progressively split as they move up the backlog.

Details were added too early if
Details were added too late if

Keep a Details in Progress limit!

Like a Work in Progress limit. About 2 sprints worth of stories, with bigger items further down.

When pairing Scrum with Kanban, the Kanban board contains the Sprint.

To keep the limit: don’t take meetings or hold conversations about items further out. Schedule those meetings for further out. If those stories are reordered lower in the meantime, cancel the meeting.

(Anecdotally, one BA went from a 60-80h work week to joining the team for happy hour in one sprint by doing this.)

2. Backlog Refinement as a Meeting

This is like having a meeting for programming. Refinement is an ongoing activity of the team, and does not require everyone to be present for all of it. Estimation should still be done all together.

3. Horizontal Slices

Small vertical slices is the common factor in successful software teams. (Uh, source? Not Project Aristotle)

Teams can learn to slice stories vertically in about 3 45m sessions by doing this exercise:

  1. Look back at done items and ask, “how should we have split this?”
  2. Look forward in the backlog and ask, “how are these items like the ones we did in the past?”

4. Allowing Technical Dependencies to take over

The Enabler (or Chore) item is an anti-pattern that helps to hide or avoid more complex scenarios where the user gets value.

This rears its head often in Business Intelligence/Data development. The antidote is that for Data work, the PBIs should be questions that the user wants to answer using reports or tools like Power BI. Start with the most interesting/valuable one!

5. Acceptance Criteria as a contract

“We have to nail down all the details before we can build this”

“You didn’t put that in the AC, so that would be a separate story.”

Details are emergent! Before coding begins, have enough detail to start and not enough to finish.

So What Did You Actually DO?

with Lyssa Adkins

Agile Coaches are the 21st century’s leaders. Trying to account for what they do by 20th century (industrial) means is necessarily missing the point (like dividing a moving train into boxcars).

What coaches do is invisible from outside the team.

Making other people more effective and accountable

The question “what did you do?” is meant to get at “what is your worth?”, usually from someone paying you.


Coaching Agile Teams, p. 280