This document provides an overview of various agile topics that are explained simply by Brian Link of PracticalAgilist.com. It covers running effective standups and understanding agile roles, writing user stories and estimating work, maintaining a product backlog, having valuable sprint reviews and feedback loops, facilitating retrospectives, and connecting strategy to delivery through OKRs and roadmaps. The document emphasizes building trust within teams and cultivating an iterative, learning-focused agile mindset. It provides contact information for Brian Link and mentions his free book on 21 common agile misconceptions.

1. Brian Link
PracticalAgilist.com
Agile Topics
Explained Simply

2. Agile Topics
• Running healthy standups and basics of agile roles (SM/PO/Family)
• Effective user stories, planning sprints, estimating
• Reasonable backlog maintenance, refinement, and tips for POs and teams
• Getting value from Sprint Reviews, stakeholders, and build feedback loops
• Simple tips for great Retrospectives and teaming in general
• Uncomplicating strategy, OKRs, roadmaps, connecting families to delivery
• The key aspects of the Agile Mindset and why its important
Brian Link - PracticalAgilist.com

3. Standups and Roles

4. Effective daily standups
• What’s the desired outcome of a standup?
• Flow, transparency, awareness, and identify opptys for collaboration and help
• Do you have to recite the same 3 questions?
• Naw. Just talk. Only highlight what matters. It’s not a status report.
• Does the Scrum Master facilitate?
• They can. But it’s almost better if they don’t. Cuz it’s for the team!
• Should the PO be there?
• Strictly speaking, they are optional. But super helpful when they can answer questions for the team
• Round robin or Walk the wall?
• Whatever works! But everyone should try walking the wall (right to left) because it makes sure the team
covers everything and is aware of stuff that just got finished
• What else?
• Don’t forget to ask “what else are people doing that’s not on the board?”

5. Key Roles
• Scrum Master
• Not the boss or PM, just a “process advocate” to help keep the team effective
• Does not *drive* the process. Anyone can schedule meetings!
• Practices the art of noticing… to see how best they can serve the team
• Diplomat, universal translator, facilitator, and gentle instigator… to help bring the right people
to conversations, make sure the team isn’t missing anything
• And to help remove blockers, often by asking questions and coordinating with people on and
off team (not necessarily being the primary one to solve it all)
• Product Owner
• Voice of the customer, domain/SME, keeper (not inventor) of the vision
• Owner of the backlog, but not creator of every single user story!
• Prioritizes and sequences backlog *with the help of* the team + stakeholders
• Has connection to (and delegated authority from) the business, for whom the team serves
• Sets DoR and asks lots of questions to choose the right work. And says NO!

6. Effective User Stories, Sprints,
and Estimates

7. What makes a User Story effective?
• Three C’s and INVEST as a guide to create a small, easy to understand nugget of work. Exact language not as
important as being clear and concise
• Utilize acceptance criteria to decorate and expand upon the WHY and WHAT while still avoiding the HOW
• During Sprint Planning we ask “what’s still not clear about this?” (of the PO herself) as well as the team to
evaluate (and refine) the Definition of Ready
• Is this something we would celebrate and tell people about after it’s done? Then it’s valuable! (If not, is it a
necessary output or stepping stone we’d tell our bosses we got done that was important?)
• Can it be broken down further? Are there any unknowns? Do we use slippery verbs like “manage” or
“consider” or anything fuzzy? With unknowns, pull them out and tackle them first with simple yes/no
timeboxed activity called a spike, to better inform the user story you’d like to write
• Does it feel like only 2-3 days or work at most? Good target – if it feels bigger there’s likely a reason and we
should try to break it down
• Of INVEST, really focus on independent and let it include any testing or validation so you really know it’s
done and “launchable” when finished

8. Effective estimating + sprint planning techniques
• First of all, if you get good at breaking work down to a similar size, you have no need to estimate because
you can just count cards
• Meanwhile, if you do still have variety, use nice big chunks like S/M/L and nothing XL gets into a sprint. Any
piece of work bigger than a week is tricky
• Use relative size estimating because everyone sucks at estimating, so let’s just suck consistently! Agree on an
anchor “medium” as an example to do relative sizing
• Velocity is best used as an average of your ability to deliver work (DoD) and is only for the team’s sake to
guide how much work to take on. Nothing else.
• Less time spent on estimating means more time spend on doing real work, so balance time spent carefully
until you get into a rhythm
• Don’t overload sprints. There are no agile awards… or agile police.
• If something new comes up mid-sprint that is super related and you can totally get it done, then just do it.
New card to track it usually helps. If it comes up and is in fact delay-able, then put the new card in the
backlog to be prioritized.
• Why does everyone’s voice count? Because we all forget things and even the freshest eyes can help us be
better! A PO and SM should encourage involvement when writing stories, identifying gaps, and planning the
sprint goal

9. Product Backlog Maintenance +
Refinement Tips

10. Product Backlog maintenance and refinement
• POs generally don’t wait for refinement sessions to work the backlog, it kinda happens ALL the time…
anytime anything comes up that helps us learn more
• POs bring the right people to refinement conversation(s) – whoever they need to make sure we’re not
missing something
• Have an algorithm. Moscow. PACE. CoD. WSJF. Something besides HiPPO.
• How often should you do refinement? I dunno, how messed up is your backlog? As often as is necessary to
keep “enough” stuff ready to go.
• Remember, if all we did was sit around and detail out every single thing in our backlog (including HOW work
gets done) we may as well use a waterfall process. Just in time with balance is more powerful.
• POs ask good questions of the team. What else? What am I missing? Is there anything unknown in here?
Who else should we ask? Could this be smaller?
• The art of making a nice backlog is the same as the art of planning the right experiments that the team will
learn from to design/build the best outcomes
• If something’s not quite ready, we need more conversations to get it to that happy level of “shared
understanding” where we all nod our heads

11. Product backlog tips
• Put stuff – anything, anytime, in the backlog! Crazy ideas from the shower too.
• Don’t be afraid to delete things – if it’s important someone somewhere will bring it up again
• A mature team will look at the big ugly things down the backlog and realize when they need to start talking
about something in order for it to be ready by the time they should start working on it
• Bugs and retrospective items belong in your backlog too because they’re real work too
• If you discover something (a flaw, a bug, an issue) while you’re working on it – think about whether it could
be done separately and delivered later. It usually can if we challenge ourselves to think incrementally.
• It’s OK to queue things up in your mind (tentatively) for future sprints… “this is probably next sprint… and
this might be for the sprint after” – you’ll verify and validate before those sprints get started anyway
• You don’t need the formalism of a refinement session to “figure something out and update a user story”, just
go do it. Just got have the conversation and update the card when you have an answer. And… anyone can do
that!

12. Sprint Reviews, stakeholders, and
feedback loops

13. Having effective Sprint Reviews
• Put stuff – anything, anytime, in the backlog! Crazy ideas from the shower too.
• Don’t be afraid to delete things – if it’s important someone somewhere will bring it up again
• A mature team will look at the big ugly things down the backlog and realize when they need to start talking
about something in order for it to be ready by the time they should start working on it
• Bugs and retrospective items belong in your backlog too because they’re real work too
• If you discover something (a flaw, a bug, an issue) while you’re working on it – think about whether it could
be done separately and delivered later. It usually can if we challenge ourselves to think incrementally.
• It’s OK to queue things up in your mind (tentatively) for future sprints… “this is probably next sprint… and
this might be for the sprint after” – you’ll verify and validate before those sprints get started anyway
• You don’t need the formalism of a refinement session to “figure something out and update a user story”, just
go do it. Just got have the conversation and update the card when you have an answer. And… anyone can do
that!

14. Stakeholders and Feedback loops
• The PO should have a very long list of anyone that has a vested interest in the success of their product or
service. We have internal and often external stakeholders. The list may even include other 3rd parties.
• If they cannot attend Sprint Reviews, send a recording or a summary of the release notes, questions, and
brief overview of what’s being worked on next. They will find a cadence to attend if it’s important.
• Often feedback may come in “why can’t we” or “how might we” and we may need to discuss as a team how
to incorporate that feedback into meaningful work
• Everything we do should be small and iterative in nature. That way we can ask questions like “What do you
like so far? Can you see where we’re going? Does it make sense? What would make this more valuable?”
which creates feedback loops with our stakeholders
• Sometimes we need to paint the picture of the steps we’re taking so there isn’t too much criticism on the
absences in the early releases. The end picture or vision is important to help others understand our
approach
• Don’t shy away from describing “hidden work” that might not easily be demonstrable. It can help paint the
whole picture so stakeholders or users understand (see this log, it proves the API is working)

15. Retrospectives and Teaming

16. Great Retrospectives
• Most agilists will tell you the retro is the most important agile event / ceremony. It’s because this is where
continuous improvement and the iterative mindset begins
• Ester Derby’s five steps help set agenda. Set the stage (open), Gather data (ideas), Generate insights
(analyze), Decide what to do (actions), Close (improve)
• SM can/should facilitate, but consider an outside, trusted voice to help should the SM want or need to
participate
• Allow at least 1.5 hours so it’s not rushed. Best to pick a new space (even if you’re virtual!) and even better
to do them face to face offsite end-of-day somewhere
• Psychological safety is required. Teams must be comfortable sharing (or work on building trust first).
Managers only allowed cautiously by invite (discouraged)
• Keep parking lot. Take notes. Share freely with team, but keep private to others (can sometimes be sensitive
discussions).
• Try different structured convos. Good/Meh/Bad. Sailboat. Starfish. Lean Coffee. Avoid routine to keep active
involvement and interest levels up. Try retromat.org
• Don’t skip or skimp. Agile shines a spotlight on what’s not working. Mature teams work to solve (or escalate)
their problems together.

17. Teaming – building trust
• Agile coaches + SMs often “crank up the goofball” to do funny ice breakers, express vulnerability, watch silly
videos together, encourage laughter + sharing to bring down barriers
• Teams that get good at sharing and expressing themselves will always work better together. (Doesn’t have to
be all personal stuff either!)
• To build trust with someone in a team we often must offer it first!
• Humble Inquiry (book by Schein) says by simply asking questions we are genuinely interested in and don’t
know the answers to - is one way we build trust (especially effective for managers / authority figures but
true for everyone)
• Great ice breakers are as simple as “pick any photo on your phone and tell us something about you or
something you’ve done” (can be anything)
• Teams that share meals together naturally build relationships. Consider a pot luck or a lunch out with no
agenda just to get to know each other
• Google study “project Aristotle” found that psychological safety and the teams who spoke equal amounts of
time were more effective than any other teams (regardless of seniority, skill level, advanced degrees,
experience, etc.)

18. Uncomplicating Strategy, OKRs,
Roadmaps

19. Strategy and Roadmaps
• The best companies have a clear vision and inspire people to want to help accomplish their goals and
mission. The same is true of divisions and teams
• By aligning a team’s vision with a family / division and with the company, something very powerful happens:
every employee knows why they are valuable and how their work directly impacts customers and the
company’s success. Knowing the WHY always inspires better work.
• The vision is the collection of words or North Star that describe the high-level strategy but the OKRs help get
specific about what we’re doing now to work on achieving them
• The vision is abstract and guides the work but a roadmap provides the clarity of what work is happening in
what order to achieve the big picture goals (in decreasing degrees of clarity over Now, Next, Later)
• A roadmap and the detailed work is defined by aligning to OKRs that represent the vision (at any level: a
team, a team of teams, or a division)

20. The Agile Mindset and Why It’s
Important

21. Agile Mindset is comprised of 7 key concepts
• Iterative Mindset: Create value in small, iterative steps allowing for early and frequent feedback on each
piece of work, which helps eliminate waste and build better products faster. Be data-driven, evidence-based
and use that data to decide what to do more or less of and what to do next.
• Product Culture: Form long-lasting, durable, product teams that reflect the company’s focus, vision, and
purpose. Have a top-down vision that influences the teams’ roadmaps and day-to-day work. Prioritize
backlogs and sequence diligently. Build and support only so many products and services, and do them well.
• Customer-Centric Mindset: Include the big picture, product vision and an appreciation for WHY it matters to
users before doing anything. Don’t guess what customers want, be customer-driven and empirical about it.
• Culture of Learning: Team members share knowledge, make learning a priority, and invest in communities
that grow people and skills that benefit the company. All failures are opportunities to learn something.
• Culture of Experimentation: A Design Thinking mindset is utilized from idea formation through delivery.
Instead of requirements, think hypotheses. What’s the smallest thing we can do to learn something? Small
failures are normal and help us find a quicker path to success.
• Culture of Continuous Improvement: Teams are empowered to change and improve their own process. Self-
reflection, transparency, courage, and respect lead to a sustainable pace of value delivery and better results.
• Culture of Psychological Safety: People will not be punished or humiliated for speaking up with any ideas,
questions, concerns or mistakes. This breeds greater innovation, inclusive collaboration and a greater flow of
ideas that will impact our products, people, and company.

22. Contact and a Free Book
Brian Link - PracticalAgilist.com
brian@practicalagilist.com
linkedin.com/in/brianwlink
twitter.com/blinkdaddy
Blog: medium.com/practical-agilest
Book: AgileMisconceptions.com
Newsletter: AgileColumbus.com

24. 21 Agile Misconceptions
1. Agile makes teams go faster
2. Agile <—> Scrum
3. Agile has no planning
4. Agile is chaos with no real process
5. Being agile doesn’t require documentation
6. Agile is easy
7. We’re agile because we work in sprints
8. Just lots of meetings with stickies on a wall
9. Deadlines are not agile
10. Agile will fix all problems
11. Any team can just install Agile
12. Agile is for software projects
13. Agile doesn't need any architects
14. Eliminates the need for management
15. The Scrum Master is the team’s admin
16. Agile is new
17. Doesn't work with distributed teams
18. There are no testers in Agile
19. Agile only works for small projects
20. Scrum doesn’t scale
21. Must follow an agile framework strictly