5 ms·

"eight-hour Scrum meeting" Why are you having an eight hour Scrum meeting? Isn't that the complete opposite of what a Scrum meeting is supposed to be? 15 minu

"eight-hour Scrum meeting" Why are you having an eight hour Scrum meeting? Isn't that the complete opposite of what a Scrum meeting is supposed to be? 15 minute max, standup meeting is a Scrum.

dexterdog 10y ago
I've been involved in Scrum that became that or during crunch time somebody gets a stupid idea that there should be one at the beginning and another at the end of the day. 15 minutes really should be an absolute max as in after 15 minutes everybody just leaves regardless of how late you started. In fact you should have no more than 50 minutes per 5-day week for scrums so that anything going over 10 minutes starts counting against the rest of the week. I call them roll-under minutes. Too often the team gets too big or unnecessary meeting jockeys start attending and it all goes to hell.
s_q_b 10y ago
These days anyone with a few free hours and a month can become a "certified Scrum master." Scrum and Agile are mostly cargo cult imitations of the real methods these days.
Symbiote 10y ago
It could be the sprint planning meeting. Eight hours is even the figure given here, for a one-month sprint: http://www.scrumguides.org/scrum-guide.html#events-planning http://www.scrumguides.org/scrum-guide.html#events-planning
deleted 10y ago
[deleted]
gurkendoktor 10y ago
To be clear, I find all eight-hour meetings exhausting, be it at work, making plans for Christmas, or sitting through school. Mentioning Scrum was a red herring in this thread, but a very effective one(?!) :) I guess our meta-problem is that Scrum was a buzzword-based requirement chosen by non-programmers, so we naturally have programmers subverting the process out of spite, lots of politics and distrust, and inexperienced folks managing the whole thing in a horribly broken JIRA installation (what else?). As a result, our development team is _really_ far behind on a huge backlog of very fuzzy stories. If you realise in a meeting that you've misunderstood key requirements, there's no point going back to building the wrong thing after the time-box ends. You have to come up with a new plan, and at the same time you need to make it fit into the desired Scrum schedule, and don't break that burn-down chart or JIRA, ... Of course, at that point it is not really a Scrum meeting anymore.
- Symbiote 10y ago
  > horribly broken JIRA installation That's the first thing I'd scrap. Software to control the process doesn't help unless the team understands and wants the process, otherwise it's just an annoyance. My path towards Scrum started after a pointless and long meeting. I found some coloured memo squares and some drawing pins, and cleared everything from an old noticeboard. (This is nicer than using post-it notes on a whiteboard.) I copied out the tasks, making a rough go at splitting them into reasonably-sized things, and making my own estimates in days. I made "backlog", "this week" and "completed" columns. The resulting mess showed that the project wasn't under control, which itself was valuable. The PM and the 'customer' were then able to ditch half the requirements, and the developers could concentrate on the highest priority tasks. This wasn't Scrum, but it worked well, and led to buy-in from almost everyone that we should try Scrum. (The most important things I missed on the first go: acceptance criteria and team estimation.)

"eight-hour Scrum meeting" Why are you having an eight hour Scrum meeting? Isn't that the complete opposite of what a Scrum meeting is supposed to be? 15 minute max, standup meeting is a Scrum.

dexterdog 10y ago

I've been involved in Scrum that became that or during crunch time somebody gets a stupid idea that there should be one at the beginning and another at the end of the day. 15 minutes really should be an absolute max as in after 15 minutes everybody just leaves regardless of how late you started. In fact you should have no more than 50 minutes per 5-day week for scrums so that anything going over 10 minutes starts counting against the rest of the week. I call them roll-under minutes. Too often the team gets too big or unnecessary meeting jockeys start attending and it all goes to hell.

s_q_b 10y ago

These days anyone with a few free hours and a month can become a "certified Scrum master." Scrum and Agile are mostly cargo cult imitations of the real methods these days.

Symbiote 10y ago

It could be the sprint planning meeting. Eight hours is even the figure given here, for a one-month sprint: http://www.scrumguides.org/scrum-guide.html#events-planning http://www.scrumguides.org/scrum-guide.html#events-planning

deleted 10y ago

[deleted]

gurkendoktor 10y ago

To be clear, I find all eight-hour meetings exhausting, be it at work, making plans for Christmas, or sitting through school. Mentioning Scrum was a red herring in this thread, but a very effective one(?!) :) I guess our meta-problem is that Scrum was a buzzword-based requirement chosen by non-programmers, so we naturally have programmers subverting the process out of spite, lots of politics and distrust, and inexperienced folks managing the whole thing in a horribly broken JIRA installation (what else?). As a result, our development team is _really_ far behind on a huge backlog of very fuzzy stories. If you realise in a meeting that you've misunderstood key requirements, there's no point going back to building the wrong thing after the time-box ends. You have to come up with a new plan, and at the same time you need to make it fit into the desired Scrum schedule, and don't break that burn-down chart or JIRA, ... Of course, at that point it is not really a Scrum meeting anymore.

Symbiote 10y ago
> horribly broken JIRA installation That's the first thing I'd scrap. Software to control the process doesn't help unless the team understands and wants the process, otherwise it's just an annoyance. My path towards Scrum started after a pointless and long meeting. I found some coloured memo squares and some drawing pins, and cleared everything from an old noticeboard. (This is nicer than using post-it notes on a whiteboard.) I copied out the tasks, making a rough go at splitting them into reasonably-sized things, and making my own estimates in days. I made "backlog", "this week" and "completed" columns. The resulting mess showed that the project wasn't under control, which itself was valuable. The PM and the 'customer' were then able to ditch half the requirements, and the developers could concentrate on the highest priority tasks. This wasn't Scrum, but it worked well, and led to buy-in from almost everyone that we should try Scrum. (The most important things I missed on the first go: acceptance criteria and team estimation.)