There are schools of thought both ways.

I think the real answer lies with the rolling wave approach to planning. The closer it is to today, the more detailed the plan. The further it is on the future, the more high level it is.

I have a plan where I have 3 month deliverables in the second half of next year. My team members know what they will be doing in more or less half day increments over the next week.

Depends on how big a project.

But I generally recommend staying away from getting too detailed. Getting too detailed makes it hard for the manager to manage, get data on the status of tasks and annoying for users.

I've discussed creating task lists at this blog post: http://www.vertabase.com/blog/task-lists-and-project-management-for-creative-teams/

As a rule of thumb, for projects between 1 week and 2 months, a task should be something that a user will be allocating at least 20 hours to.

For projects 2 months or more, a task should be something a user will be allocating at least 40 hours to.

it depends on your team

if a typical software developer tells you a task will take "two weeks" then they probably don't really know how long it takes; estimates under two weeks tend to be more accurate

your team's mileage may vary; track it!

First, let's assume that we are using the WBS as a management tool for ourselves, and that our scope is well enough defined that we don't have to deal with rolling wave or similar learning-project issues. Here are some general guidelines:

1. Ask yourself, "can we estimate cost and duration accurately?" "Accurately" does not mean to 3 decimal places, but to the point where a 5-10% variance is unlikely to cause severe pain. If the answer is no, you need more detail. This implies that some activities may be larger and others smaller based on who's doing the estimating.

2. Is there one clear owner? This could be a person, a team, or a contractor. If not, break it down.

3. Are the completion criteria clear? If not, more detail.

4. Is the likely duration less than twice the reporting period? If not, another level is called for.

It depends on the kind of project, on the size of the project and the level you are at. For example: If you are a project manager at the nitty gritty level you want to be more specific than a programme manager. To take a one-level-fits-all-approach is too easy I would say. So I am sorry to say it but it really depends and there is no definite answer (which might contrast other postings).

If you want to read more about it you can google the web for books and you will find a few sources. One might even be the PMI book of practice for WBS where my knowledge is from.

With discrete deliverables I recommend no WBS elements smaller than roughly 80 hours of effort. This is a rough guess when you are doing it, because when defining your WBS you haven't yet done thorough estimation. You can go back and iterate when you do get to estimation though.

For service deliverables it can be different. Since the WBS should contain 100% of your project scope, there will be services that get charged to your project and are in support of your project that are really LOE (level of effort) activities. For instance, routine system administration and backups, project management and controls, configuration management, etc. For these kind of WBS elements I break them down to the smallest useful breakout, not necessarily in terms of how big they are in terms of hours or cost.

You go to the lowest level that you can estimate and assign a task, and still be able to manage it.

I wrote an article called Breaking Down The Work Breakdown Structure that you can read here: http://www.expiriance.com/blogs/pm/2009/10/breaking-work-breakdown-structure.php.

I use the less then 2 weeks (80 hrs) rule too. I also try and get to the level that gives me 80% confidence. In the beginning of a data warehouse project we estimated each table down to the design, code, and test level. But, after about 100 tables, the team had enough experience to estimate at the table level for small, medium, and high complexity. So, we raised the WBS one level.