MoSCoW: A saviour while planning Software Development
A real-world example of applying MoSCoW in agile software projects
As an engineer, I always found it hard to prioritize my work when there are a lot of micro-level tasks. And those get way harder once I started taking responsibility as a senior engineer and beyond. Then the problem is tenfold.
First, you have to understand the feature or mission at hand.
Then you need to break those down into smaller technical stories.
Then you need to execute it.
I also forgot to mention the nitty-gritty details of every aspect of delivery planning, requirements analysis, back-and-forth planning, cross-team dependency, understanding micro and macro level requirements, etc.
A few years ago, I found the MoSCoW method. And since then, it’s been helping me prioritize my work and my team’s work.
MoSCoW is
Must Have
Should Have
Could Have
Won’t Have
I found this while attending a big non-technical meeting called MoSCoW. The main agenda of the meeting was to set goals for the team/company using this method. I took the idea to use it in tech planning.
So, how does it work in real life?
A simple project requirement: Add a Support ChatBot in the Existing Website (PoC)
Let’s add some imaginary facts/constraints:
We need it in 4 weeks / 2 sprints
It’s a PoC
We will follow agile development
This feature will have to comply with security features
This feature will have future support
Our facts will help us navigate through the requirements. Now let’s look into the MoSCoW:
Must Have:
An interface to send and receive messages
A BE application to provide read and write APIs
A DB to store data without user personal info
Access to an LLM to process the stored data and reply
User auth-specific validations
Unit tests in API to e2e flow
Should Have:
Code should be isolated enough to split it later
Data should be stored in chunks to support future isolations
Validation in API fields
Each function should have unit tests
Refresh button to reload chat
Long polling support
Could Have:
External API should have mocks
Background processing for the call from the API to the LLM
Ability to scale the application to 10X
Async processing for data saving
Could have access to previous user data
Won’t Have:
MicroService architecture
ChatGPT-like thinking
Chat GPT-like streaming response (HTTP/2 protocol support)
Vector DB
Circuit Breaker Pattern
real-time communication
This is just a quick example I made from the top of my head. We can plan our main features in many ways. The point I am trying to make here is how to use the format to support our need. The rest is up to you.