4 ms·

The #1 point mentioned in the article was my experience as well. For a tight deadline project if we decided to do everything based on the complexity points and

by g123g 14y ago

The #1 point mentioned in the article was my experience as well. For a tight deadline project if we decided to do everything based on the complexity points and team velocity it would take 6 sprints and a total of 3 months. But we just decided to ditch it and sit around a table and finished the whole thing in 2 weeks straight. So my experience is that if you are working with a dedicated team it is better to finish the work based on the best of your ability rather than time boxing into some artificial time limits.

kevingadd 14y ago
How would Scrum turn a 2 week project into 3 months? Are you just saying you were terrible at estimation, or what? I don't understand what you ditched, specifically, and how that produced an improvement.
- SoftwareMaven 14y ago
  In timeboxed iterations, you have to be very careful that work doesn't expand to fill all available time. If you are a little conservative with your estimates, its easy to double the time the necessary aspects of development would take. Little, unnecessary tweaks becomes more important than putting four hours into the stretch goal that is going to spill into the next sprint. Six times is a bit much, though. That sounds like they haven't worked out their estimations yet.
knighthacker 14y ago
Having a dedicated team is definitely important. I had a similar experience to yours and I am not entirely sure why. I think a big part of it is that once you dig into complexity points and time estimates and all that other stuff, people tend to be on the safe side and add a lot of buffer. But when the whole team is in the hacking mentality and just wants to get sh*t done, you don't need to have everything in sprints. You just need a highly motivated and a dedicated team.
skMed 14y ago
Are you trying to say the overhead of SCRUM would increase the time to 3 months? SCRUM is a lightweight framework, so I am struggling to see how this could happen. Alternatively, do you think the estimation with points was the main problem and you couldn't get a correct feel for doing it without resulting in a conservative estimate?

by g123g 14y ago

kevingadd 14y ago

How would Scrum turn a 2 week project into 3 months? Are you just saying you were terrible at estimation, or what? I don't understand what you ditched, specifically, and how that produced an improvement.

SoftwareMaven 14y ago
In timeboxed iterations, you have to be very careful that work doesn't expand to fill all available time. If you are a little conservative with your estimates, its easy to double the time the necessary aspects of development would take. Little, unnecessary tweaks becomes more important than putting four hours into the stretch goal that is going to spill into the next sprint. Six times is a bit much, though. That sounds like they haven't worked out their estimations yet.

knighthacker 14y ago

Having a dedicated team is definitely important. I had a similar experience to yours and I am not entirely sure why. I think a big part of it is that once you dig into complexity points and time estimates and all that other stuff, people tend to be on the safe side and add a lot of buffer. But when the whole team is in the hacking mentality and just wants to get sh*t done, you don't need to have everything in sprints. You just need a highly motivated and a dedicated team.

skMed 14y ago

Are you trying to say the overhead of SCRUM would increase the time to 3 months? SCRUM is a lightweight framework, so I am struggling to see how this could happen. Alternatively, do you think the estimation with points was the main problem and you couldn't get a correct feel for doing it without resulting in a conservative estimate?