4 ms·

> Iteration planning meetings are seriously expensive. I completely agree on this one. I've worked in several corporate environments utilizing Srum and the pla

> Iteration planning meetings are seriously expensive. I completely agree on this one. I've worked in several corporate environments utilizing Srum and the planning meetings were always a huge waste of time. I would rather light my hair on fire than sit around a bunch of PM's trying to figure out what features to include/exclude. Also, most of the people (PM's,Dev's,IA's) I talk to always say, "Nobody does Scrum/Agile right anyways." Which made me wonder if there is indeed a right and wrong way to do these.

skMed 14y ago
Perhaps it is the environment or Product Owners that are causing this slow down? Product Owners (PMs, etc.) should stack rank items in their backlog before a sprint planning meeting. This should make it fairly easy to allocate items for a sprint and identify features which either need to be 1. clarified, 2. split/scoped down. My sprint planning sessions have typically always gone smoothly as long as everyone came prepared and ready to contribute.
jt2190 14y ago
In my experience most teams do planning completely wrong. The goals of the planning meeting are simply: 1. Do a relative-size estimate the top n stories in the backlog. (Where n is some number slightly larger than the number of stories that usually fit in an iteration.) 2. Pick the stories to complete in the iteration. That's it. I often see teams: * doing one-by-one story estimation, and debating over how many points to assign. (The statistical method completely fails when it's done this way.) * getting into long discussions over the spec. (That's between the dev and product owner, to be figured out during the iteration.) * worrying too much about accurate estimates * worrying too much about how much work to take on
- smhinsey 14y ago
  I think the reason this happens is because no matter what people say, the idea that if you can't finish a story within a sprint it will simply slide into the next one is anathema. People spend more time on estimation when the consequences of mistakes are higher. If you can't realize that a story is larger than you thought and reprioritize mid-sprint without it being equivalent to missing a deadline in your old model, it's not going to work. In my experience this is the key failure mode of scrum.
  - michaelfdeberry 14y ago
    I agree, but I think some of the pressure for accurate estimates come from managers wanting to track employee time. I had a manager that would pretty much go through the board and ask who did what card so he compare the estimates to the actual time.
- jim-greer 14y ago
  Do you really think one-by-one story estimation is that bad? At Kongregate it's about 8 people doing it, for 45 minutes or so every couple of weeks. It isn't the most fun thing in the world, but I do think it's helpful to spend between 30 seconds and a few minutes talking about how hard something's going to be. If it seems hard, easier ways are often suggested... If you're not looking at them one by one, what are you really doing? Why not just say all stories are the same difficulty?
  - jt2190 14y ago
    > talking about how hard something's going to be. The planning meeting isn't the right place to review the implementation approach of every story. That's best left to another discussion among the technical team, probably in a design review.[1] Discussion isn't necessary for estimation purposes when the team agrees on effort. It's only necessary when the team can't agree where to rank the story's effort in relation to other stories, both completed and upcoming. (You need completed stories in there to "anchor" the story points, otherwise the meaning of a point will drift from iteration to iteration.) Once the team has ranked most stories, the team can return to those that they can't rank, and discuss them a little further until they can fit them into the rankings. [1] It could be that the team isn't communicating enough, and that the planning meeting is the only time they're forced to communicate.
vannevar 14y ago
I would rather light my hair on fire than sit around a bunch of PM's trying to figure out what features to include/exclude. Me too. Good thing neither activity has anything to do with sprint planning.

skMed 14y ago

Perhaps it is the environment or Product Owners that are causing this slow down? Product Owners (PMs, etc.) should stack rank items in their backlog before a sprint planning meeting. This should make it fairly easy to allocate items for a sprint and identify features which either need to be 1. clarified, 2. split/scoped down. My sprint planning sessions have typically always gone smoothly as long as everyone came prepared and ready to contribute.

jt2190 14y ago

In my experience most teams do planning completely wrong. The goals of the planning meeting are simply: 1. Do a relative-size estimate the top n stories in the backlog. (Where n is some number slightly larger than the number of stories that usually fit in an iteration.) 2. Pick the stories to complete in the iteration. That's it. I often see teams: * doing one-by-one story estimation, and debating over how many points to assign. (The statistical method completely fails when it's done this way.) * getting into long discussions over the spec. (That's between the dev and product owner, to be figured out during the iteration.) * worrying too much about accurate estimates * worrying too much about how much work to take on

smhinsey 14y ago
I think the reason this happens is because no matter what people say, the idea that if you can't finish a story within a sprint it will simply slide into the next one is anathema. People spend more time on estimation when the consequences of mistakes are higher. If you can't realize that a story is larger than you thought and reprioritize mid-sprint without it being equivalent to missing a deadline in your old model, it's not going to work. In my experience this is the key failure mode of scrum.
- michaelfdeberry 14y ago
  I agree, but I think some of the pressure for accurate estimates come from managers wanting to track employee time. I had a manager that would pretty much go through the board and ask who did what card so he compare the estimates to the actual time.
jim-greer 14y ago
Do you really think one-by-one story estimation is that bad? At Kongregate it's about 8 people doing it, for 45 minutes or so every couple of weeks. It isn't the most fun thing in the world, but I do think it's helpful to spend between 30 seconds and a few minutes talking about how hard something's going to be. If it seems hard, easier ways are often suggested... If you're not looking at them one by one, what are you really doing? Why not just say all stories are the same difficulty?
- jt2190 14y ago
  > talking about how hard something's going to be. The planning meeting isn't the right place to review the implementation approach of every story. That's best left to another discussion among the technical team, probably in a design review.[1] Discussion isn't necessary for estimation purposes when the team agrees on effort. It's only necessary when the team can't agree where to rank the story's effort in relation to other stories, both completed and upcoming. (You need completed stories in there to "anchor" the story points, otherwise the meaning of a point will drift from iteration to iteration.) Once the team has ranked most stories, the team can return to those that they can't rank, and discuss them a little further until they can fit them into the rankings. [1] It could be that the team isn't communicating enough, and that the planning meeting is the only time they're forced to communicate.

vannevar 14y ago

I would rather light my hair on fire than sit around a bunch of PM's trying to figure out what features to include/exclude. Me too. Good thing neither activity has anything to do with sprint planning.