MUST vs. SHOULD vs. COULD
Whether I'm dealing with software requirements, or I'm prioritizing my personal TO Dos, I think in terms of MUST, SHOULD, COULD. It's simpple but effective.
Here's an example of some scenarios and usage:
- getting a quick handle on my day - what MUST I do today? what SHOULD I do? What COULD I do?
- prioritizing my personal backlog - what MUST I do today? what MUST I do this week? What should I do? What could I do?
- focusing my teams - what MUST we release this week? What SHOULD we release this week? what COULD we release this week?
- brainstorming sessions - what COULD we do? What SHOULD we do? what MUST we do?
- determining an incremental release - what are the MUSTs for this software release? What are the SHOULDs? What are the COULDs?
- helping a customer identify their security objectives - What security constraints MUST be met for this software?
- helping a customer identify their performance objectives - what performance constraints MUST be met for this software?
It's easy to get lost among SHOULDs and COULDs. I find factoring MUSTs from the SHOULDs and COULDs helps get clarity around immediate action.
Comments
Anonymous
March 17, 2007
Building software involves a lot of communication. Behind this communication, lies perspectives. TheseAnonymous
March 17, 2007
Why don't you just say that you are using the MoSCoW prioritisation system popularised by the DSDM methodology? :-) You just forgot to mention the Wish (aka "Would like to but will not this time round")Anonymous
March 19, 2007
I'm rolling my own task management database [!] so I found this post somewhat useful -- now I will separate Crucial tasks from Important, Useful, and Optional. Thanks!Anonymous
March 25, 2007
How do I efficiently and effectively prioritize my day ... my week ... my life? In an earlier post, IAnonymous
June 11, 2007
If you're backlogged and you want to get out, here's a quick, low tech, brute force approach. On yourAnonymous
June 21, 2007
Hello! Good Site! Thanks you! jdpbpxpuhhc