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 (6)

  1. Building software involves a lot of communication. Behind this communication, lies perspectives. These

  2. DanielMoth says:

    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")

  3. NET says:

    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!

  4. How do I efficiently and effectively prioritize my day … my week … my life? In an earlier post, I

  5. If you’re backlogged and you want to get out, here’s a quick, low tech, brute force approach. On your

  6. nnrbrvxjts says:

    Hello! Good Site! Thanks you! jdpbpxpuhhc