4 ms·

So what I want to know, is, as per all the recent agile/scrum discussions - how does the modern "do sprint planning/commit to a number of sprint points to do/ta

So what I want to know, is, as per all the recent agile/scrum discussions - how does the modern "do sprint planning/commit to a number of sprint points to do/tasks to work on/be the product manager's monkeys" align with, "you saw something that's probably representative of a major problem in your system, but stopping what you're doing to investigate it will kill your velocity, and make your team's statistics look bad"?

isaacaggrey 12y ago
Any time a sprint commitment must be broken the decision rests on the team's product manager who is best (or _should_ be best) suited to understanding the tradeoff between sprint completion and a potential emergency bug situation. If the PM decides it's not worth it, then that's on them. It's worth noting, you may want to include a wide enough distribution so it's known that you noticed but PM didn't want you to work on it in order to cover yourself. As for how to account for that work in your velocity, I don't believe it is realistic to size a story for fixing a potential issue (not to mention the difficulties in sizing bugs anyway [1]). However, it is possible (or at least a bit easier) to size a story for research that answers a specific question as its acceptance criteria -- in this case, the acceptance criteria for this article's situation would've been something like 1) "will latency continue to rise?" and 2) if so and it is unacceptable, what is the cause and add an implementation story to the backlog" Some may say "well, how do you know how what is causing the issue", and if no one really can figure it out the answer to the research story question and the bug has manifested itself as an emergency, then sure your velocity will tank as you break the sprint(s), but it's up to the team/business to understand how to remove outliers for an accurate velocity. [1]: http://www.agileforall.com/2010/05/agile-antipattern-sizing-or-estimating-bug-fixes/ http://www.agileforall.com/2010/05/agile-antipattern-sizing-...
- optimusclimb 12y ago
  Yeah, I figured someone would respond that way. I have a feeling that the more process that lies around making such fixes...the more likely the system is likely to be under performing (and or broken) long term.
  - isaacaggrey 12y ago
    In Scrum, speed and efficiency are traded for predictability and consistency (whether or not those trade-offs are worth it is another conversation). It's worth noting that I agree with your point and also don't believe Scrum is a panacea, but I am starting to understand its appeal from a business perspective.
mvc 12y ago
Your sprint budget should be some percentage less than the average velocity over the past 3 sprints. That allows for bugs to be fixed mid-sprint without affecting velocity. Velocity shouldn't be used to measure how "good" the team is.
trustfundbaby 12y ago
I came here to make this point ... engineering organizations applying scrum or agile make no allowance for something like this. And while you might dig deeper, find a problem that indeed would have been a major crisis, and in some cases get to add that as a Product support ticket, after the fact, if you're lucky, the reality is that a lot of times you'll spend a lot of time investigating, learn that much more about your infrastructure/codebase but find its a small (but not insignificant problem) that gets thrown on the backlog, while the PM seethes at you for screwing up team velocity, and going "rogue" (working on a problem without telling him). Or, maybe, even worse ... you don't find anything, now you just wasted a day on nothing. Of course you could say something in standup about it, but you and I both know you'd probably be gently admonished for wasting time on it and asked to go back to what you were doing. because ... sprint goals, quarterly objectives yada yada yada. If you make doing this enough of a habit, it might show up in your one on ones and evaluations even. There goes your big annual raise. In essence, you have to do your work AND go figure out these sorts of things on your own time. Thats how you find yourself putting in 50-60 hour weeks, but its okay because you're a "passionate" engineer. Either way The business wins.

isaacaggrey 12y ago

Any time a sprint commitment must be broken the decision rests on the team's product manager who is best (or _should_ be best) suited to understanding the tradeoff between sprint completion and a potential emergency bug situation. If the PM decides it's not worth it, then that's on them. It's worth noting, you may want to include a wide enough distribution so it's known that you noticed but PM didn't want you to work on it in order to cover yourself. As for how to account for that work in your velocity, I don't believe it is realistic to size a story for fixing a potential issue (not to mention the difficulties in sizing bugs anyway [1]). However, it is possible (or at least a bit easier) to size a story for research that answers a specific question as its acceptance criteria -- in this case, the acceptance criteria for this article's situation would've been something like 1) "will latency continue to rise?" and 2) if so and it is unacceptable, what is the cause and add an implementation story to the backlog" Some may say "well, how do you know how what is causing the issue", and if no one really can figure it out the answer to the research story question and the bug has manifested itself as an emergency, then sure your velocity will tank as you break the sprint(s), but it's up to the team/business to understand how to remove outliers for an accurate velocity. [1]: http://www.agileforall.com/2010/05/agile-antipattern-sizing-or-estimating-bug-fixes/ http://www.agileforall.com/2010/05/agile-antipattern-sizing-...

optimusclimb 12y ago
Yeah, I figured someone would respond that way. I have a feeling that the more process that lies around making such fixes...the more likely the system is likely to be under performing (and or broken) long term.
- isaacaggrey 12y ago
  In Scrum, speed and efficiency are traded for predictability and consistency (whether or not those trade-offs are worth it is another conversation). It's worth noting that I agree with your point and also don't believe Scrum is a panacea, but I am starting to understand its appeal from a business perspective.

mvc 12y ago

Your sprint budget should be some percentage less than the average velocity over the past 3 sprints. That allows for bugs to be fixed mid-sprint without affecting velocity. Velocity shouldn't be used to measure how "good" the team is.

trustfundbaby 12y ago

I came here to make this point ... engineering organizations applying scrum or agile make no allowance for something like this. And while you might dig deeper, find a problem that indeed would have been a major crisis, and in some cases get to add that as a Product support ticket, after the fact, if you're lucky, the reality is that a lot of times you'll spend a lot of time investigating, learn that much more about your infrastructure/codebase but find its a small (but not insignificant problem) that gets thrown on the backlog, while the PM seethes at you for screwing up team velocity, and going "rogue" (working on a problem without telling him). Or, maybe, even worse ... you don't find anything, now you just wasted a day on nothing. Of course you could say something in standup about it, but you and I both know you'd probably be gently admonished for wasting time on it and asked to go back to what you were doing. because ... sprint goals, quarterly objectives yada yada yada. If you make doing this enough of a habit, it might show up in your one on ones and evaluations even. There goes your big annual raise. In essence, you have to do your work AND go figure out these sorts of things on your own time. Thats how you find yourself putting in 50-60 hour weeks, but its okay because you're a "passionate" engineer. Either way The business wins.