My experience has been that no one needs a burndown chart to know how a project is going, and, to the extent that you do, it usually points to some mismanagement and an attempt to fix it through intensifying project management rigor. Especially with early stage startups, where the requirements are changing rapidly and throughout the project, I think this stuff represents very real overhead that's just not really that useful. In larger companies, where stuff like this is typically used as reporting up a chain, it can be slightly more useful to get a holistic view of the organization, but again, I'm just not sure it's worth the effort, and I really question resting a significant amount of decision making power on this over qualitative data.<p>To be clear: I'm not throwing all project management methodology to the wind, but this promises to give you a fancy chart that will "identify bottlenecks in your development process" and I'm sorry if you need a graph to know where those are I think there are probably larger problems in your organization. Identifying bottlenecks is easy, fixing them usually involves much higher level management functions like recruiting and training.
I feel like the use of metrics is often just a crutch to avoid real management/leadership decisions. Sprints are meaningless overhead unless they are coupled to important deliveries. Often they aren't.<p>In my real world experience software doesn't get delivered within sprints, it gets delivered when it's ready. And decisions about what to deliver aren't made by the sprint team.<p>Anyone can pad story points enough to look like a sprint super-hero. The key focus should be what are you building, are you building it the right way, and what can we do to deliver it faster/better. Sometimes the right answer is stop holding meetings, and just get out of the way and let the team focus on the problem without interruption for a while.