Category: verified

Posted on

The Scrum Master’s field guide to a newly formed scrum team

This guide is a list of suggestions you can implement as a Scrum Master when you are joining a newly formed scrum team. However, many of the suggestions described here may be useful in case you become Scrum Master for an existing scrum team.

Read the complete article here: https://medium.com/@clausreestrup/the-scrum-masters-field-guide-to-a-newly-formed-scrum-team-first-steps-462f41026884

Posted on

Hand retrospective

Je maakt gebruik van je eigen hand. Je geeft iedere vinger een betekenis in relatie tot de afgelopen sprint. Je laat mensen nadenken over hun eigen functioneren en over het functioneren van het proces. Tegelijkertijd activeer je mensen om actief mee te doen. Teken zelf een hand op een whiteboard, door je eigen hand over te trekken. Schrijf bij de vingers:

Duim: Wat ging er goed?
Wijsvinger: Wat is jouw doel voor de komende sprint?
Middelvinger: Wat ging er niet goed? Wat wil je wegnemen uit het sprint-proces?
Ringvinger: Waar geef jij commitment voor af, de volgende sprint?
Kleine vinger: Wat is jouw persoonlijke zwakte?
(Vooral de kleine vinger is daarbij een afwisseling die het geheel persoonlijker maakt.)

Vervolgens vraag je aan het team om hun invulling op geeltjes te schrijven (5 minuten timeboxed). Hierna vraag je de teamleden om omstebeurt hun eigen hand op het bord over te trekken, waarna ze de geeltjes bij iedere vinger hangen en uitleg geven.

as copied from:  https://www.scrum.nl/blog/retrospective/
Posted on

Things to consider if you are finding too many problems during your sprint reviews

Scrum’s sprint reviews are intended to surface issues that customers, users and stakeholders may have with the team’s work of the current sprint.

But sometimes, too many issues are identified. Not only can these be brutal for the team, Scrum Master, and product owner to sit through, having a lot of issues identified during the sprint review is a strong indicator that the team’s process could be improved.

Here are a few things to consider if you are finding too many problems during your sprint reviews.

  • Run shorter sprints. Finding a lot of problems in the review often indicates the team has gone astray in understanding users’ needs. They might find that shorter sprints give them more feedback opportunities.
  • Talk more often. One of the best ways to ensure team members are building what’s needed is for them to talk with users and customers more frequently. They don’t have to wait for sprint reviews to get a better understanding of what their users need.
  • Be sure you’re talking to the right people. Talking frequently won’t be helpful if team members are talking to the wrong users and customers. If you’re finding too many problems during the review, be sure the team is talking to the right people.
  • Demo early and often. Augment your conversations with users by giving them informal demos of what is being built as it’s being built.

In addition to trying one or more of these fixes, use the retrospective to discuss why so many issues were found during the review.

Finding problems isn’t necessarily a problem itself, but finding them as late as the sprint review is.

Addressing that and finding issues earlier will help your team succeed with agile,

Mike Cohn

Posted on

Overcoming Four Common Objections to the Daily Scrum

Some meetings are helpful and worth the time investment. Mike Cohn puts well-run daily scrum meetings in that category.

In this article, Mike Cohn shares how he handles four common objections to participating in daily scrums.

  1. We Talk A Lot Already
  2. Nothing Important Is Ever Discussed
    1. Set Expectations
    2. Determine if the Objection Is Valid
  3. Can’t We Just Do This by Email?
  4. The Meetings Take Too Long

He then shares some attributes of a well-run daily scrum so that there will be no objections to participating.

  1. Meetings Are at the Same Time and Place Each Day
  2. Meetings Start on Time
  3. The Meetings Are Kept to No More than Fifteen Minutes
  4. Problems Are Identified But Not Solved in the Meeting
  5. Participants Stay on Topic
  6. Rules Are Enforced by the Whole Team, Not Just the Scrum Master
  7. The Whole Team and Only the Team Participates

Read the complete article here: https://www.mountaingoatsoftware.com/blog/overcoming-four-common-objections-to-the-daily-scrum

Posted on

Truth, Lies, and Scrum

is a great article from Zach Bonaker in which he describes that:

  • Scrum is not equal to Agile;
  • Your context and culture dictates Scrum’s effectiveness;
  • Your organization will likely need a new structure to use Scrum;
  • The Scrum Guide is not a straw-man document;
  • Daily Scrum is a feedback loop.
  • Scrum Master is not a role “in agile”;
  • Scrum Masters are not a sign or assessment of “maturity”.
  • User stories are not part of Scrum;
  • The outcome of the Sprint Review is an updated product backlog;
  • Velocity is not part of Scrum;
  • If retrospectives have no organizational impact, you’re not doing Scrum;
  • Teams are the heart of Scrum, but a bunch of people with the same boss are not necessarily a team;

Read the complete article here: https://agileoutloud.wordpress.com/2019/07/16/truth-lies-and-scrum/

Posted on

Story Point Estimates Are Best Thought of as Ranges

When estimating with story points, most teams use a predefined set of values that doesn’t include every possible number.

One of the questions I often get about story points is what to do if you can’t decide whether a particular product backlog item should be an 8 or a 13 (or a 3 and a 5). Part of the answer can be found by thinking about water buckets.

Suppose you have 10 liters of water you need to store. You also have an 8-liter bucket and a 13-liter bucket.

Which bucket would you store the water in?

The 13-liter bucket, right? Ten liters of water doesn’t fit in an 8-liter bucket. The water would overflow and spill out.

Extrapolating further, you’d use the 13-liter bucket for all amounts of water from 9 liters through 13 liters. Once you hit 14 liters, though, you’d once again need a bigger bucket.

And so it is with the values you choose to use when estimating stories. Think of each value as a bucket. A value bucket is used for all stories between that value and the next lower value.

Read the complet blogpost here: https://www.mountaingoatsoftware.com/blog/story-point-estimates-are-best-thought-of-as-ranges