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.
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.
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
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.