You need some coarse odometer to know where the finish line is. Burn-up charts are a reasonable input to that and can be very low effort. Just knowing where you hit the inflection point between new-issues added to a milestone vs. issues resolved is useful. If you can replace a burn up chart with tangible test results matrix or similar - even better.
> retrospectives
I have never found per-sprint retros useful, either. I guide teams to do a retro when the issues raised in the previous retro are resolved. WIP control FTW.
> poker sessions
In my experience, planning sessions are one of the most impactful parts of the stereotypical scrum process for three reasons: (a) Planning creates a consensus within the team about what the story actually means; (b) Planning often leads to someone proposing a good 80/20 trade-off or raising an important point that avoids future re-work or unexpected tech debt. (c) Breaking big tasks into actionable, independently useful, small tasks is one of the hardest things for junior developers to learn. A lot of mentorship and teaching happens in good planning meetings. I encourage teams to try planning for the benefits of the process and not worry at all about fine grained points - "trivial", "medium", "unknown" is typically enough. Lots of mature teams will plan ad-hoc as they are ready for new work. This is my personal preference. But teaching teams how to plan effectively in a weekly planning meeting is often a good starting point.
> daily stand-ups
Standups that are control points for managers and expensive status gathering shortcuts are horrible. standups that are self-organizing, especially for teams that have ops + dev responsibilities, can be really useful. Nothing wrong with making a plan for the day - it should just take 10m.
> user stories and related tickets (eg in JIRA)
You should write down what you want to do somewhere and a few checklists go a long ways towards improving quality management.
I have never found scrum to be a good process (like the article, I find it very grinding) and I strongly agree with the posted article. But a good dev process likely includes all of these elements in some shape.
You need some coarse odometer to know where the finish line is. Burn-up charts are a reasonable input to that and can be very low effort. Just knowing where you hit the inflection point between new-issues added to a milestone vs. issues resolved is useful. If you can replace a burn up chart with tangible test results matrix or similar - even better.
> retrospectives
I have never found per-sprint retros useful, either. I guide teams to do a retro when the issues raised in the previous retro are resolved. WIP control FTW.
> poker sessions
In my experience, planning sessions are one of the most impactful parts of the stereotypical scrum process for three reasons: (a) Planning creates a consensus within the team about what the story actually means; (b) Planning often leads to someone proposing a good 80/20 trade-off or raising an important point that avoids future re-work or unexpected tech debt. (c) Breaking big tasks into actionable, independently useful, small tasks is one of the hardest things for junior developers to learn. A lot of mentorship and teaching happens in good planning meetings. I encourage teams to try planning for the benefits of the process and not worry at all about fine grained points - "trivial", "medium", "unknown" is typically enough. Lots of mature teams will plan ad-hoc as they are ready for new work. This is my personal preference. But teaching teams how to plan effectively in a weekly planning meeting is often a good starting point.
> daily stand-ups
Standups that are control points for managers and expensive status gathering shortcuts are horrible. standups that are self-organizing, especially for teams that have ops + dev responsibilities, can be really useful. Nothing wrong with making a plan for the day - it should just take 10m.
> user stories and related tickets (eg in JIRA)
You should write down what you want to do somewhere and a few checklists go a long ways towards improving quality management.
I have never found scrum to be a good process (like the article, I find it very grinding) and I strongly agree with the posted article. But a good dev process likely includes all of these elements in some shape.