Same, except it's Jira and Confluence. Everything has to have story points assigned to it just so we can say we did an arbitrary number of points per sprint and show a impressive looking graph in retrospectives.
About showing burn down chats: usually they are shown a few times in early stages of the project, but don't get any attention anymore once they start showing unwanted or erratic results.
Also story points estimations/tracking (as opposed to time in real world units) : never saw it work in practice.
Whoever says software/hardware project time schedules are 'under control' or 'predictable' is probably joking.
If your management can't understand these charts - including when you get results you don't want - I think your management is failing.
E.g. if you don't realize "whoa there's a lot more ambiguity here than we expected and it's causing big delay" until the project goes sideways trying to find clarity, then you missed something big in your earlier planning and estimation.
And whether or not it was important to spend the time to try to get a more accurate estimate vs just start building should be a business-requirement and project-specific decision, but it should be a conscious one.
If you have a manager that's treating N points as a target, then you just have a bad manager. Sprint points are just a signal for how over/under your estimates are on average, to help inform future planning. If someone goes on vacation, how do I know how much work the remaining team can handle? It's also a good signal for measuring the impact of team/process changes (to be clear, the idea here is post hoc analysis and not +N points as a target).
That said, how would you prefer to handle capacity planning? Points aren't perfect, but trends should stabilize over time (you can have predictability/consistency without precision). You can even map point values to ranges of time (e.g. 1 point = [2, 8] hours) if it helps.
It's the beaurocratic gamification aspect I despise.
Having 2 meetings. 1 for task presentation and 1 for task estimation next day is really great
It is the only solution I've ever seen for the "documentation always gets cut" problem with SWE. Someone's whole work stream is thorough documentation and knowing everything. How features work, what customers requested them, what technical trade-offs were made and why.
I miss having one of these people every day at $dayjob. She would make reports for questions that's needed a thorough response. I asked what I thought was an innocent question about what a small kafka cluster was used for and I got back a long-ass document that outlined the whole saga, the complaints the customer had, the VP discussions, the MRs that introduced it, other things people proposed and why they were shot down, meeting notes, screenshots of the discussion on Slack. Like hot damn.
Today that role is filled by either a) nobody or b) the lowest lackey who doesn't give a hoot about the concept.
It turns into an exercise where the Notion document becomes the goal, rather than a tool to help get work done.
The Product Management group at my last company was the worst at this. They had hundreds of Notion pages that supposedly collected everything and show them in meetings, slide decks, and at every chance they had as proof that they were on top of things. Yet they could barely do any product management work that we needed to ship product because their whole world revolves around building Notion pages rather than building products.
The sad part was that it worked, at least for a while. Executives would praise the team for being so organized and always having so much to show in presentations. Eventually people started to realize that they were lost in the process of writing Notion docs rather than focusing on getting work done, but it took a long time.