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

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

Definition of Ready

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

Have you ever started work on a user story that wasn’t ready to work on yet? Create a Definition of Ready to establish reasonable guidelines as to what conditions need to be met before you pull a user story into a sprint or begin work on it. Creating and following a Definition of Ready could double the speed of your team.

Click “Continue reading” below for a transcript.

(more…)

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

Tradeoff Matrix

Here’s a video I shot for freeCodeCamp about the Tradeoff Matrix.

When we work on projects with fixed dates, scopes, and resources, we run the risk of burning out our teams and compromising quality. Use the tradeoff matrix to agree with your stakeholders as to what you’ll do when things—almost inevitably—don’t go exactly as planned.

Click “Continue reading” below for a transcript.

(more…)

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

Mary Poppendieck’s “The Tyranny of ‘The Plan'”

A couple of years ago, my former manager David Denton forwarded me a recorded presentation by Mary Poppendieck, a leading Agile software development expert and co-author of the popular book “Leading Lean Software Development: Results Are not the Point.

Watching the video on the InfoQ website is a bit kludgey and Mary has lots of wonderful details that are worth hearing. So, with Mary’s permission, I’ve had the video transcribed and included her slides in context. I hope that this will make this very useful knowledge easier to find and learn from. Mary, thanks again.

I’ve eschewed block-quote formatting as it made this transcript a little harder to read. I’ve also edited slightly for readability. Otherwise, everything beyond this point is Mary’s work.

(more…)

2014-03-11T21:07:03-08:00September 20th, 2012|9 Comments
Go to Top