Using Zoom polls for planning poker in Agile teams

Planning poker cards
Planning Poker cards from Mountain Goat Software

A couple of years ago, I wrote a post about using planning poker in Agile teams, for estimating user story size. But that was when we were all sitting in the same room and not shielding from Covid-19.

Things have changed now. Here are a few options that I’ve tried.

Continue reading Using Zoom polls for planning poker in Agile teams

What rules do you have for meetings at work?

A meeting room at work that I haven’t sat in now for over a year

Hands up if you love meetings… nobody?

It’s one of the most common complaints I hear from development teams: “Urgh! We have far too many meetings.” It’s not often true but that is their perception because the meetings felt boring and wasteful.

Meetings don’t have to be like that. I’ve just started reading a book called Meeting Design: For Managers, Makers and Everyone by Kevin M Hoffman (Two Waves Books, 2018) which I’m hoping will help me plan more productive, more meaningful gatherings in the future.

In this post, I offer a few simple rules to help meeting feel more manageable.

Continue reading What rules do you have for meetings at work?

Instead of focusing on better estimates…

This tweet from John Cutler has been challenging me recently:

Instead of focusing on making ‘better’ estimates, focus on:

  • working smaller
  • integrating frequently
  • exposing work to users/customers sooner
  • testing assumptions earlier
  • limiting dependencies
  • less fragile code
  • limiting handoffs

Your estimates will improve.

Why?

Why do we focus so much on estimates?

We focus so much on estimates because we want certainty, because we want to feel like we are in control and are directing progress.

Development teams want to know how much work they think can be done during a sprint. Management wants to know when new features will be finished, when deadlines will be met. Customers want to know when they can get this new functionality.

And so we develop systems that give us a sense of security even though they may be false.

But human beings are terrible at estimating. Just read this article on Wikipedia about the planning falacy to see just how much.

Psychologists Daniel Kahneman and Amos Tversky explained the planning fallacy by suggesting that planners focus on the most optimistic scenario for any task, rather than using their full experience of how much time similar tasks would take.

Curiously, when asked to estimate how long something will take, people will generally underestimate how long they would take and overestimate how long they think others would take to do the same task. In other words, people will consider the best case scenario for themselves and the worst case for others.

Originally posted on my work internal blog.

What is a Definition of Ready?

Runner in the blocks, ready to race.
Photo by Braden Collum on Unsplash

While the Scrum Guide encourages teams to create a Definition of Done so that everyone understands what ‘done’ means, it says nothing about creating a Definition of Ready so that everyone understands what pre-conditions must be met before a user story may be allowed onto a sprint.

Continue reading What is a Definition of Ready?

Marginal gains for development teams

Header photo by Rob Wingate on Unsplash

Happy new year!

Human beings have seemingly been making new year’s resolutions for around 4,000 years. There is something about the year incrementing by one that somehow encourages folks to examine their past failures and vouch to do better in the year ahead.

And yet, research (and plenty of personal experience) shows that around 80% of resolutions will be broken by the second week of February.

There is a better way.

Continue reading Marginal gains for development teams