Comments on: The Absurdity of MoSCoW Requirements

By: HEEL LIFTS

HEEL LIFTS — Mon, 21 Dec 2009 02:07:01 +0000

Fantastic work. You have gained a new reader. I hope you keep up the good work and I look forward to more of the same excellent posts.

By: TKirk

TKirk — Wed, 01 Jul 2009 23:30:48 +0000

Hi Josh,
Interesting post. Reminds me of the term “unique.” Either something is unique or it is not.

I have written requirements for different purposes. When requirements are used for estimating, then the priority helps the estimating team determine when (or if) to include the item, and in which phase.

Even as I write this I wrestle with “is it a requirement then?” Or is it just a feature?

Scrum calls them product backlog. Until it’s being developed, it’s just in the list of things that might be next on the block.

Interesting notion. Thanks for the brain food.

By: Josh

Josh — Thu, 02 Oct 2008 22:12:23 +0000

Thanks, Kredit. Glad to hear it.

It might be interesting… as much as I think MoSCoW is kind of kooky in the classic sense, I have been getting a lot of mileage out of Prioritization lately.

Thanks for the note. Love to get new readers.

- Josh

By: Kredit

Kredit — Thu, 02 Oct 2008 16:07:46 +0000

I have this informativ site bookmarked. Thanks from Kredit

By: Josh

Josh — Thu, 20 Mar 2008 19:30:11 +0000

I agree totally – like Barely Good Enough Use Cases… Not ‘the green text will blink at a nice rate’ requirements. Hard declarative truths. Thanks for the comment.

By: Steve Campbell

Steve Campbell — Thu, 20 Mar 2008 19:25:39 +0000

“Having defined requirements does not inhibit Agility. It *engages* Agility”

This depends on your definition of requirements. Part of being Agile is the separation of goals from implementation – the customer has goals, and the developers implement something based on those goals. Requirements that specify implementation details limit agility. Requirements that specify *goals* engage agility.

For example, contrast: “The user enters their login id and password and clicks on the Ok button” with “the user authenticates to the system”. One leaves the implementation open to discussion and the other tells the developer how to do it (when he may have better ideas on the actual implementation).