About Chris Gagné

This author has not yet filled in any details.
So far Chris Gagné has created 136 blog entries.

A Useful Technique: MoSCoW

MoSCoW is an acronym of sorts that stands for Must-, Should-, Could-, and Won’t-Have.

It’s most commonly used when conducting release planning to give stakeholders and teams a short-hand for scope flexibility.

On a release plan board, it may look like this:

Note that we’ve indicated Must, Should, Could, and Won’t to the left of the release planning board.

  1. Must-have means exactly that. If even one must have condition isn’t present by the time we want to release, we won’t release. They are critical to the project’s success. These should be no more than 60% of your release scope. If your team is new and doesn’t have a known, stable velocity, consider limiting this to 40%.
  2. Should-haves are also important, but not absolutely necessary for the release. Limit these to about 20%.
  3. Could-haves are desired but not necessary. If we’ve got the time and resources, we’ll include them in the release. These make up the balance.
  4. Having a “Won’t” section allows us to give early warning to stakeholders about the desired backlog items that are unlikely to be in the release.
  5. If you’re working towards a release or major milestone, indicate it in your plan. It can be located anywhere, it doesn’t have to be at the end. Adjust your MoSCoW indicators accordingly.

Typewriter image: Prioritize by Nick Youngson CC BY-SA 3.0 ImageCreator

2018-05-07T14:56:42-08:00May 6th, 2018|0 Comments

A Useful Technique: “Fists-of-Five” voting

It’s often useful to get a “gut check” on the likelihood of a sprint or release plan being successful. If you’re a new team and don’t have an established velocity, this “Fists-of-Five” gut check might be all the data you have.

To perform a “Fists-of-Five” vote, every member of the team votes on the likelihood of a plan being successful on a 1–5 scale. Describe the scale below, then vote together on the count of three.

fists of five

Fists of Five voting technique

In general, it’s acceptable to proceed if everyone votes 4 or 5. If someone votes a 3 or less, ask them what it might take to vote a 4 or 5.

For instance, suppose all of the developers vote 4 or 5, but the user experience researcher votes 2. Ask why. They may tell you that there are too many items that require their skill set in the sprint. They may be willing to vote a 4 or 5 if some of those items are replaced with developer-oriented items. Then vote again.

2018-05-07T14:56:32-08:00May 6th, 2018|0 Comments

Three key benefits of meditation and mindfulness in knowledge work environments

As an Agile coach and meditation teacher-in-training, I regularly spot opportunities where Agile and mindfulness are aligned. Here’s a summary of the three key benefits of meditation and mindfulness in knowledge work environments that routinely come to mind for me. I’ve given this as a talk at Agile Open Northern California 2017 and I’d be delighted to share it elsewhere as well.

(more…)

2018-01-12T15:19:28-08:00October 2nd, 2017|3 Comments

The Essence of a Successful Agile Transformation

Focusing on just tools and processes during an Agile Transformation is like rearranging the deck chairs on the Titanic. You are ignoring significant structural and cultural issues at your peril, and are only guaranteeing a cold, dark fate. All leaders at all levels of the organization must transform into true, humble servant leaders. No exceptions. If you can manage this, you will accomplish in a week what it takes your competition a quarter. You will absolutely. eat. their. lunch.

2017-09-13T19:57:05-08:00September 13th, 2017|0 Comments

I.N.V.E.S.T.

Here’s a video I shot for freeCodeCamp about the I.N.V.E.S.T. mnemonic.

I.N.V.E.S.T. is a great starting point for your team’s Definition of Ready. In this brief video, you’ll learn what the mnemonic means and gain insight into a frequently required but often overlooked addition.

Click “Continue reading” below for a transcript.

(more…)

2017-09-19T16:20:06-08:00July 25th, 2017|0 Comments

The Agile Manifesto

Here’s a video I shot for freeCodeCamp about the Agile Manifesto.

The Agile Manifesto describes the fundamental values upon which every Agile framework rests. In this brief video, you’ll learn what the full Agile Manifesto is, along with a little history of how it was created.

Click “Continue reading” below for a transcript.

(more…)

2017-09-19T16:20:06-08:00July 24th, 2017|0 Comments

On Leaders and Safety

Safety is a mandatory prerequisite for the success of any Agile transformation.

Leaders cannot create safety for teams if they do not feel safe themselves. This is influenced not by the leaders they report to (including the board), but also whether or not they have overcome their own insecurities.

2017-07-24T13:24:15-08:00July 21st, 2017|0 Comments

Definition of Done

Here’s a video I shot for freeCodeCamp about the Definition of Done.

The Definition of Done is a documented team agreement. It defines the conditions that must be met for a potentially shippable product to be considered “done as in done.” It’s how we know that we “did the thing right”, meaning that we built in the correct level of quality into the product. These are different from the acceptance criteria which help us know that we did the “right thing.”

Click “Continue reading” below for a transcript.

(more…)

2017-09-19T16:20:06-08:00July 10th, 2017|1 Comment

Working Agreements

Here’s a video I shot for freeCodeCamp about Working Agreements.

Does your team show up late to meetings? Does Sprint Planning take forever because half the team isn’t paying attention to anything but social media? Find out how to identify and limit these and other big risks with a Working Agreement.

Click “Continue reading” below for a transcript.

(more…)

2017-09-19T16:20:06-08:00July 3rd, 2017|0 Comments
Go to Top