4 ms·

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

by fleischhauf 5y ago

nicoburns 5y ago
Easy enough in my experience. You just build in time for these projects into your estimates.
- newswasboring 5y ago
  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)
  - nicoburns 5y ago
    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.
    - lostcolony 5y ago
      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.
  - lostcolony 5y ago
    '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.
newswasboring 5y ago
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.
- papito 5y ago
  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.
  - deleted 5y ago
    [deleted]
Aeolun 5y ago
I’m sorry, my task just isn’t done yet, it is much more work than was estimated.
sumtechguy 5y ago
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'.
- aqme28 5y ago
  In my professional experience, scrum often means that 100% of your time is tracked. Should it be that way? No, but it sometimes is.

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

nicoburns 5y ago

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

newswasboring 5y ago
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)
- nicoburns 5y ago
  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.
  - lostcolony 5y ago
    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.
- lostcolony 5y ago
  '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.

newswasboring 5y ago

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.

papito 5y ago
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.
- deleted 5y ago
  [deleted]

Aeolun 5y ago

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

sumtechguy 5y ago

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'.

aqme28 5y ago
In my professional experience, scrum often means that 100% of your time is tracked. Should it be that way? No, but it sometimes is.