At what resolution does this look like a cliff though? Let's say we're building Google Mail. This is a project with a life of perhaps 30 years. Throughout th

At what resolution does this look like a cliff though? Let's say we're building Google Mail. This is a project with a life of perhaps 30 years. Throughout the project we obviously need to think and deliver. We can't think for 29 years and then start working. Let's zoom in to some 2 week cycle in this project. If you don't actually know what you need to get done during those two weeks it's too late to start thinking about it. You want to be in a situation where you've already identified some features you need to deliver and you already have a pretty good idea about how they'll be delivered and how they fit into the architecture etc. That "how to/thinking" stage is just background processing that happens all the time. It shouldn't be counted in the burndown. That background processing could consume anything between 100% of the time in a project that is just getting kicked off and 20% of the time in a more mature project. Every now and then a problem might come along that requires more serious thought. But to just have the entire team go and think about it for months is very rarely the right thing to do. You just put it on the back burner. If there's some urgency then you just think quickly and accept the fact that the solution is very unlikely to be perfect. Regardless of process or how management is trying to drive people you need some mix of stuff that gets done and thinking about what else needs to be done and where to steer the overall project towards. These really have to happen somewhat concurrently since you want to get feedback on your ideas as soon as reasonably possible. Every situation is different in terms of the time scale and what this mix looks like. Whatever the buzzword of the day bad management will find a way to abuse it. Agile was supposed to be a way of avoiding that but the forces it tries to fight are too strong. EDIT (more thoughts). If you've thought about architecture and how features work and are implemented than tracking burn-down can indeed give you some insight about the actual progress being made. It's just a visual way of seeing how close you are to where you thought you'd be. There are a lot of things that need to happen though for this to really work. You need to have done the thinking. You need to be reasonably good at estimation. You need to be reasonably good at planning the work out. The team needs to understand what "done" actually means. The process shouldn't be abused by management (which I think is the complaint?). I've seen this work. I've seen "smooth" work reflected as smooth burn down charts and I've seen "oops, unexpected trouble" show charts where nothing is burnt. That early visibility is supposed to help steer the project. I've seen projects with no such visibility go through 2 years and find out very close to the end that they're really a year late and the project will take 3 years. It's not that something unexpected happened after a year and 11 months. It's just that people weren't paying attention and were being optimistic they would somehow magically catch up.