4 ms·

If the project manager throws out a feature description like that, just say "Yes" and throw it to the bottom of the backlog - it'll be revisited when it's well

by debacle 14y ago

If the project manager throws out a feature description like that, just say "Yes" and throw it to the bottom of the backlog - it'll be revisited when it's well defined.

Domenic_S 14y ago
The product backlog? The engineers don't control the product backlog. This strategy falls flat when the PM committed to a stakeholder that they'd get a feature done without defining it well or resolving dependencies, so now we have to sit for 15 minutes hammering it out. Note that I'm not totally disagreeing, but textbook scrum and what-happens-when-people-spend-a-lot-of-money-to-develop-something scrum often diverge greatly. The ultimate business purpose of scrum is to manage expectations. What's going to be done, when's it going to be done, if something's stuck who is responsible, etc. If the PM starts making wild promises and setting crazy expectations -- which PMs are wont to do -- all the methodology in the world isn't going to save you.
anthonyb 14y ago
No - because you're not the business owner and don't decide what order things go in the backlog. A better way is to just give a sufficiently large estimate: "That's 100 points* due to risk and uncertainty." If they want a more detailed estimate, then they have to give a more detailed story. * - whatever will give you 6 +/- 3 months
- tetha 14y ago
  This is one of the best things an older programmer has taught me. If people want estimations on vague things, give them 8 month full team full time. Minimum. Doesn't matter what it is. Implement a new, small feature? 8 month. Move the office furniture around? 8 month. People talking to you learn quickly to give out more precise specifications.
  - anthonyb 14y ago
    I should point out that just throwing out a 100 point story over nothing is a bad plan career-wise - you definitely need to be able to back it up with reasons (we need to interface with systems x, y and z, this is comparable to other system w which took 8 months, we don't have any spec for doing a, b or c). In that sense the 100 point estimate is a real one - a "small" feature (eg. add a form to your web site) might be two or three weeks of work.

by debacle 14y ago

If the project manager throws out a feature description like that, just say "Yes" and throw it to the bottom of the backlog - it'll be revisited when it's well defined.

Domenic_S 14y ago

The product backlog? The engineers don't control the product backlog. This strategy falls flat when the PM committed to a stakeholder that they'd get a feature done without defining it well or resolving dependencies, so now we have to sit for 15 minutes hammering it out. Note that I'm not totally disagreeing, but textbook scrum and what-happens-when-people-spend-a-lot-of-money-to-develop-something scrum often diverge greatly. The ultimate business purpose of scrum is to manage expectations. What's going to be done, when's it going to be done, if something's stuck who is responsible, etc. If the PM starts making wild promises and setting crazy expectations -- which PMs are wont to do -- all the methodology in the world isn't going to save you.

anthonyb 14y ago

No - because you're not the business owner and don't decide what order things go in the backlog. A better way is to just give a sufficiently large estimate: "That's 100 points* due to risk and uncertainty." If they want a more detailed estimate, then they have to give a more detailed story. * - whatever will give you 6 +/- 3 months

tetha 14y ago
This is one of the best things an older programmer has taught me. If people want estimations on vague things, give them 8 month full team full time. Minimum. Doesn't matter what it is. Implement a new, small feature? 8 month. Move the office furniture around? 8 month. People talking to you learn quickly to give out more precise specifications.
- anthonyb 14y ago
  I should point out that just throwing out a 100 point story over nothing is a bad plan career-wise - you definitely need to be able to back it up with reasons (we need to interface with systems x, y and z, this is comparable to other system w which took 8 months, we don't have any spec for doing a, b or c). In that sense the 100 point estimate is a real one - a "small" feature (eg. add a form to your web site) might be two or three weeks of work.