Hacker News Reader

Comment by sethg | Hacker News Reader

In my experience (six months at a job that does Scrum and, I think, does it very well), the thing that slows down iteration planning meetings is when the product manager hands down a one-sentence feature description, the engineers say “we can’t size that, it’s too vague”, and then you need a five-to-fifteen-minute discussion in order to expand that one sentence into something resembling a spec.

View on HN

That is the same with any planning/management technique, but unfortunately something that people still keep getting wrong.

No technique will allow you to reliably and efficiently solve a problem until the problem is well enough defined.

I've seen that happen.

These are exactly the sort of problems that should show up in sprint retrospectives. Hopefully folk then generate ideas for solving them (e.g. PO breaking down stories further before the planning meeting, or devs getting more up to speed in the problem domain so they can grok brief feature descriptions more easily).

So - what's happening in your sprint retrospectives?

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.

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.

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

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.

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.

Reply on news.ycombinator.com