Hacker News Reader

Comment by fleischhauf | Hacker News Reader

So you work in some scrum framework with tasks and sprints? I wonder how feasible that is in frameworks like that

The only way I've found innovation happening in scrum is by cheating the system. Either by inflating time estimates or attaching your idea to something which is just a by product.

Right, but the ultimate goal is to help the company succeed and save it from itself and its management, which is just ass-backwards.

At some point I stopped bothering. I can't worry about the company more than the company worries about itself. I think that's fair.

Scrum does not mean 100% of your time is tracked. You usually have some % of time dedicated to your tasks. I usually pick 70% as that works pretty good for me. It allows for '30% other' to get in there and not having to track every detail. If something becomes big enough I bring it to the team and say 'hey I would like some dedicated time to work on this lets add a story to the board'.

In my professional experience, scrum often means that 100% of your time is tracked.

Should it be that way? No, but it sometimes is.

Easy enough in my experience. You just build in time for these projects into your estimates.

Isn't that cheating the system though? Giving an inflated time estimate is lying to your team. While this gets the job done, I don't think it should be encouraged.

(Just a disclaimer, I do it too)

I guess I just see it as part of doing my job. I wouldn't be able to do it effectively if I didn't do this.

I don't think it's ever been secret in companies that I work for that devs don't spend 100% of their time on assigned tasks. There are always extra things like customer support, ops, urgent requests, unexpected refactoring that come up and have to be dealt with. Project managers I've worked with have mostly cared about the estimate being as accurate as possible taking into account these overheads.

The places I've worked that required time estimates (the wrong way to do it) still built in an overhead factor of ~30-40%. I.e., recognized that a dev would only put in 4-5 hours of 'coding' a day, with the rest taken up by meetings and random miscellany.

'An inflated time estimate' - well there's your problem. If it's a point estimate, as it should be, it's quite easy to do. Your 'real' velocity may be 10 points, but your planned velocity is 7. That not only gives you a little buffer in the event of something unexpected (so you're less likely to miss a sprint commitment due to things your team controls), but in the event nothing takes that time, it's free time to work on what feels important.

I’m sorry, my task just isn’t done yet, it is much more work than was estimated.

Reply on news.ycombinator.com