Change is not uncommon, change in requirements, change in specs change in workflow. I've accepted that there will be change, but I wonder: knowing that change is going to happen, how short of a planning period is too short? (Justifications are encouraged)

  • An iteration (2-4 weeks)?
  • A week?
  • A 2-3 day period?
  • A day?
  • 1/2 a day?

Assume that the company 'plans' 1 [time interval (from above)] in advance from the current so that any plan sounds like:

"[this morning/today/this week/etc.] you'll work on this and [this afternoon/tomorrow/next week/etc.] you'll be working on that.

Also assume that the changes in focus/direction will consistently occur every second to third time interval.


I'm a Scrum Practitionner so I'll will suggest you to use it.

  1. Define the duration of your iteration. I like two weeks iteration in startups, and one month in large enterprise projects
  2. At the beginning of an iteration, select from the features you will develop from the product backlog. Nobody has the right to change the iteration plan, not even the product manager.
  3. Changes occur in the product backlog, not in the iteration plan. Therefore, you are never affected in your work.

More details about Scrum


Planning to often tends to make the bigger picture get lost in all the details, and you just end up spinning your wheels. That is a huge risk.

I prefer using XP (or Scrum) which says that you should plan once at the beginning of each iteration, which I find most effective when they are 1-2 weeks in length.

Having said that, there are some very cool things in Kanban which encourages planning to happen when needed, though I personally think Kanban is better suited for maintenance and support situations rather than when starting development from scratch.


I break things down like this:

  1. Any significant project/application development - 1 week.
  2. Simple one-off enhancements are thrown into a list, prioritized, and each one gets addressed in half to full day periods.
  3. Bug fixes usually take priority and go through a similar process as #2, but can sometimes be fixed much quicker.

The key factor here is how much planning can you actually do for a given task? Starting a brand new website that does yadda, yadda, yadda, there is more planning up front than fixing a bug. Who plans bugs in advance? Department manager discovers they forgot something and need it for the end of the quarter reporting, you have to put things aside and work on it.

A weekly iteration may have 10 hrs or may have 50. It all depends on how much other stuff is immediate. I think it is much easier for management to understand the time contraints when you ask, if you should put a project aside to make a small addition? I'm pleasantly surprised when they identify that little change as unecessary and I should keep working on the yadda-yadda-yadda-website.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.