Effective Scheduling is all about prioritization.  When thinking about feature priority I initially assign features into buckets using the MoSCoW method:

• M - MUST have this.
• S - SHOULD have this if at all possible.
• C - COULD have this if it does not affect anything else.
• W - WON'T have this time but WOULD like in the future.

This is a good technique to focus on what's most important first for the user: The MUST Haves.

If you don't do this type of prioritization/triage continuously, there will be the tendency to see all the features that you are aware of as important, and you will become drawn toward Big Design Up Front (BDUF).  In BDUF, you plan out every detail of the project before you begin implementation, with a detailed specification document to guide you every step along the way.

There is a fundamental issue with BDUF, which is that it presumes that you know everything that you will need to implement for the project before you actually do it.  In reality, there are always unknowns in a project, and you will become aware of those as you progress, and those unknowns will significantly affect your schedule in ways you could not have anticipated prior to knowing about them.

It's very easy to get lulled in to a false sense of security when you put down a list of features and you think you have captured the full scope of what you need to achieve. "Hurray, we have a plan, the plan will save us!"

To counter this, I try to practice lucid ignorance, being consciously aware of "Knowing what I don't know" in the project. This practice combined with implementing the Must Have features first, will help ensure that what I'm developing at any given point in the project will bring the most value to the user and that the value will increase over time maximally.

Ultimately, it's about giving the user the features they want most as early as possible.

In my next post I'll talk about estimation.

--Altay