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+00:00 May 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+00:00 May 6th, 2018|0 Comments

On Doing Versus Being Agile

Are you doing Agile, or have you become Agile?

The difference seems pedantic at first…

You are doing Agile when you’ve changed your tools and processes. This is relatively easy to do but doesn’t offer much in the way of benefits. You’ve become Agile when you’ve changed you structure and culture too. This is relatively hard to do, but offers significant benefits.

Agile isn’t just a process. It’s a complete framework that brings together a shift in culturestructure, and processes. This framework is supported by tools such as Rally and other Agile Lifecycle Management (ALM) tools.

(more…)

2017-07-10T11:16:54+00:00 March 19th, 2016|0 Comments