Timeline for How to deal with unavoidable on-demand tasks in Scrum? Or should we even try?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 21, 2021 at 20:43 | comment | added | Toby Speight | Is there a particular reason to measure in hours, rather than story points? My team measures pretty much all effort in story points, and we never stop to think how much time a point is likely to take. | |
| Oct 24, 2018 at 15:02 | comment | added | Jonathan Benn | In my experience, this technique is simple to implement but has hidden costs. The multi-tasking leads to reduced efficiency for all team members. If, for example, each team member has 1 day worth of interruptions per Sprint, I have found that the actual effect on the team is a loss of 3 days each. Team members spend 1 day ramping up on the new task, 1 day executing the new task, and then 1 day switching contexts to their original task. This adds up to a major velocity loss for the team. | |
| Aug 5, 2015 at 19:20 | comment | added | DrewJordan | Also useful since you can use the lower capacity % as an incentive to the company. For example, if you plan on 90% capacity for the team, and get 40 story points per sprint, you should be able to get 44 if you didn't have those interruptions. Keep in mind also, possible solutions for these interruptions. If you could give your users some kind of stripped down data editing tool that would let them fix at least some of their problems on their own, that's worth doing, isn't it? | |
| Aug 5, 2015 at 18:10 | comment | added | Jeff Lindsey | I've also found the above to be the "lesser-of-all-evils"/simple and useful approach as well. Just measure how much time or points the side work is for a few iterations, and then factor it into planning (and continue to measure it for more accuracy, deviations, etc.) | |
| Aug 5, 2015 at 17:02 | history | answered | Jill Sanderson | CC BY-SA 3.0 |