I my current team (working on a variety of Business Intelligence software projects), we've recently started adopting a variant of classical "agile" project planning and estimating -- everybody seems to be pretty happy with it so far, including us (developers of different levels of experience), the product managers (highly technical people, typically also with some development experience, but mostly interested in the business side of things), management (pretty technical at the level we report to, but also less-technical, more-businessy directors and VPs), and other stakeholders (users and would-be users of our software). But, of course, it is early times, and we'll adjust as we go along. (In the past few years I used other variants of this in very different application areas, such as cluster management software; but I've often also used more ad-hoc, less-structured approaches).
The outline is as follows. At each iteration (we're currently on 2-week iteration cycles), the PMs choose some "elementary units of business value" that they might like to get from projects in our area -- a typical unit would be one feature, a bug fix, some optimization aspect, etc. In a small meeting with tech leads and one or two senior engineers, each unit is decomposed into engineering tasks (and dependencies among tasks are identified). In a larger whole-team meeting, the relative "cost" of each task (how much time, roughly, it will take to perform that task relative to other tasks) is collectively assessed (we're using completely abstract units of effort we call "points", though I've seen other teams use less abstract units such as "ideal engineering-days"). The costs assessed include unit testing and technical documentation.
The tasks, each with its assessed cost, go on what's called "the backlog" for the team, together with "internal restructuring" tasks (typically refactorings that will deliver no new user-observable plus, but will make further development and maintenance more productive), also with assessed costs and a summary of expected benefits (which must be expressed in ways understandable to the PMs -- fortunately, as I said, ours are highly technical people). A refactoring may also, by engineering team consensus, be deemed a prerequisite of certain business-requested tasks (e.g. "makes no sense to work further on component X until class Y, too large, is properly split, which will take N points").
The PMs now get to order the tasks in the backlog in any way they prefer, based on the business value that completing the units those tasks make up would deliver, subject to the dependency constraints. They have a good idea of roughly how many "points" the team may accomplish in a 2-week iteration (our "velocity") based on past results, so they try to make sure some business-valuable release can be performed at the end of the iteration (as opposed to having many business-valuable thingies "in flight"... but none completed and deliverable to stakeholders yet!-).
The team then devotes about 80% of its time and effort to tackling the top-priority tasks as designed by the PMs (including pair programming some of the time, for particularly urgent tasks or for situations where one team member needs to learn more about some technology or some part of the codebase, and another team member who's an expert in those is available for pairing up with them for a while). The priority order is an important indication, but it's not entirey rigid (e.g. if the top task requires extensive work in Java, and the second one requires it in Python, I may well pick the second one, as my relative productivity will be enormously higher that way -- and vice versa for a team member who's a Java guru, etc etc).
"Priority 0" aka "Code Red" issues may arise at any time, and, if they do, by definition they will take priority over any other task (and be accounted for only retroactively in the planning, to make sure velocity is assessed properly). But, as we do a pretty good job with testing, release engineering, and other quality-assurance practices, those emergencies are fortunately few and far between.
This, plus other "mandatory" ways for engineers to spend their time (training courses, all-hands meetings, quarterly performance self-evaluations and peer reviews, etc), is supposed to account for about 80% of engineers' time -- the remaining 20% being time each engineer should devote to "something completely different" ("blue-sky" exploratory projects, "egineering community" efforts, open-source contributions, etc, etc), not directly related to the projects at hand. Nobody actually measures the hours precisely, but that's still a useful guideline (I keep thinking of ways to make measurement easy and painless that I could implement in my 20% time, to help me allocate time and effort more precisely, but I haven't actually gotten any round tuits yet;-).