Posts

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

Posted on

Deze 10 principes helpen je meer uit je interacties te halen

Of je nu de grote baas bent bij een multinational of net bent begonnen met je eerste serieuze baan, voor iedereen geldt: jouw succes in het leven is grotendeels afhankelijk van de interacties met de mensen om je heen. Hoe meer je uit die interacties haalt, hoe meer jij uit het leven haalt. Lijkt dat je wat? Dan vind je in de tien principes achter Liberating Structures een bijzonder effectieve methode om dat voor elkaar te krijgen.

  1. Betrek en activeer iedereen
  2. Respecteer anderen en wat anderen te zeggen hebben
  3. Bouw vertrouwen op terwijl je bezig bent
  4. Leer van je fouten
  5. Gebruik de groepsdynamiek om jezelf beter te leren kennen
  6. Benadruk vrijheid en verantwoordelijkheid
  7. Focus je op wat wél mogelijk is
  8. Omarm creatieve destructie
  9. Serieus spelen: Spelenderwijs ontdekken
  10. Start nooit zonder duidelijk doel

Lees het volledige artikel van Ruben Klerkx hier: https://thecreatorscompany.com/blogs/deze-10-principes-helpen-je-meer-uit-je-interacties-te-halen/

Posted on

Two Truths and a Lie

Each team member writes down 3 statements. 2 of them are true, 1 of them is not true. The statements must be about the person himself.

Examples:

  • I play the guitar
  • I speak 5 languages
  • I was picked up on an island
  • I’m a twin
  • I hate the color red

A person tells the 3 statements. The teammates may take turns guessing what is true and what is not.

More 2 Truths and a Lie ideas and examples can be found here: https://truthsandlie.com

Posted on

Building the Team Manifesto

The following text was copied from: https://www.scrum.nl/blog/building-team-manifesto/

Every time a new team is formed, it takes time to grow from a group of people to a well-functioning team. In their journey to become a high-performing team, they need a shared understanding of the principles and values of each individual and the team. The most important principles and values can be summarized in a team manifesto, a social contract among the team members. A team manifesto is always built by the team itself. It contains a set of norms, values and behaviors that forms a solid ground for collaboration within the team.

Building the Team Manifesto

With every team I coach, one of the first things we do is building a team manifesto. Recently, I did this by using the Retrospective format ‘That guy, this guy’. The results were great! Therefore, I would like to share this workshop format with you.

  1. Plan a timebox of 60 minutes with the entire team
  2. Bring flip charts, sticky notes and markers with you
  3. Create two flip charts with: ‘Don’t be that guy…’ and ‘This guy rocks!’
  4. Explain to the team what the goal of this session and a team manifesto is
  5. Ask the team members to write down characteristics associated with ‘that guy’ (the person that you don’t want in your team) and ‘this guy’ (the person that is a perfect team member) on sticky notes, individually and in silence
  6. Let the team members explain what they wrote down and collect the sticky notes on the flip charts
  7. Consider to cluster the characteristics, if there is a lot of overlap
  8. Ask the team members to prioritize the characteristics, by dot voting on the ones they value the most for the team (every team member gets five dots to divide among the items)
  9. Select the five to seven most important characteristics
  10. Divide the team in three groups and give each group a set of characteristics
  11. Ask the groups to describe what each characteristic means for the team
  12. Let each group explain what they wrote down and adjust this with the feedback from the other groups
  13. Summarize all parts of the team manifesto on one flip chart and invite each team member to commit to it, for example by writing down their signatures
  14. Make sure the team manifesto is visible at all times

A team manifesto ensures that the team coherence improves. It is a common understanding about the desired behavior within the team, and what it means for them to be a team. Since the team has ownership over the team manifesto, team members will behave according to it and encourage others to do the same.

Additional examples can be found here:

https://www.barryovereem.com/the-team-manifesto-the-foundation-every-team-needs/
by Barry Overeem

How To Kickstart A Great Scrum Team (10 practical things to do)
by Christiaan Verwijs