| My experience has been that no one needs a burndown chart to know how a project is going Indeed, you use a burndown chart to know how the current sprint is going. Don't wait until the end of the sprint to know you're late, detect problems early. I think this stuff represents very real overhead Updating a burndown chart should be a grand total of 20sec. What takes time is the discussion you have when you're late. Yes, solving problems takes more visible time than burying them :) In larger companies, where stuff like this is typically used as reporting up a chain It's a terrible tool for reporting up the chain. No reason to report the details of the sprint up the chain Identifying bottlenecks is easy It sometimes is (usually when the situation is dire), but most of the time really not. I don't know if the burndown chart is the best tool to identify bottlenecks though, at best it shows that there is some problems that might be bottlenecks. It's just a very lightweight tool so make problems immediately visible. If you find a burndown chart to be too much overhead... I don't know what tools you'll ever use |
I don't know how this is different from what I said and my point is that I don't think they are a good tool to detect problems. In most cases I would consider burn down graphs to be trailing indicators of problems, not leading, which is why I consider them more appropriate for reporting up the chain than down.
> Updating a burndown chart should be a grand total of 20sec. What takes time is the discussion you have when you're late. Yes, solving problems takes more visible time than burying them :)
Right, my point is not about checking off a ticket and letting an automatic burndown chart update. My point is about the kind of project management where you have an intense focus on the how instead of the what. It's very inappropriate for early stage startups because of how quickly requirements change. It also represents a communication overhead.
> It's a terrible tool for reporting up the chain. No reason to report the details of the sprint up the chain
We can disagree about whether or not it has value for reporting up the chain, but why wouldn't the status of a sprint be something you'd want reported up the chain?
> It sometimes is (usually when the situation is dire), but most of the time really not. I don't know if the burndown chart is the best tool to identify bottlenecks though, at best it shows that there is some problems that might be bottlenecks. It's just a very lightweight tool so make problems immediately visible. If you find a burndown chart to be too much overhead... I don't know what tools you'll ever use
We're getting semantic, it depends on how you identify bottlenecks. My experience has been it typically looks something like "a bunch of tickets are stuck in design, design is a bottleneck" which isn't really helpful when the core issue is, for instance, that you don't have enough designers. That's typically a reality most people know and understand, so I don't think it's super valuable here, nor do I think a different project management or organizational system fixes it. Interested in what you consider to be a bottleneck and how you would identify it.