Just saw this post. I’m struggling with the comparison matrix. I don’t think Agile necessarily dictates what you indicate (or that it shouldn’t do what is prescribed in the Burndown Framework)
A few points…
Success — Success in agile is not the thoroughness of the stories, or velocity. Succes is how much business valuable the software you are releasing creates. Period. Lots of people may get fixated on velocity and points, but that is bad scrum. End user adoption and retention are typically critical to creating business value, but aren’t necessarily the ‘goal’ in and of itself.
Prioritization — The backlog does not inform the prioritization, it is merely a means to communicate the prioritization. Prioritization needs to be based on the ROI (business value / effort (or points as proxy). The best way to de-risk the ability to achieve business value is to validate with customers. Again, these things aren’t prescribed by Agile, nor are they mutually exclusive of what you propose.
Speed, Release Focus, Flexibility — These three are all intertwined. Teams should constantly release throughout a sprint. Nothing dictates you can’t release until the end of the sprint (or that your sprint is a day or a week long). If you are not releasing throughout a sprint, that means you are doing ‘scrummerfall’ which is just small iterations of waterfall (and brings some of the prescriptions you have made for Agile), which is bad. If anything, these seem to be more technical decisions than anything a PM could (or should) influence (other than helping the engineers understand how what they are doing is creating business value and being motivated that the sooner you realize the business value the better off everyone will be).
I guess my major issue is the prescriptions assigned to Agile. In the same way you speak of your framework being guided by principles instead of rules, the exact same is true if you are doing good scrum. Now, scrum has been around for a long time and lots of people have bastardized it and made it seem rule based for a variety of reasons, but that’s not what it is if you read it and follow it correctly.
In the end, I’m not sure that there is much of a difference between your framework and scrum, as Adam Karmiński points out, but always love spirited debate!