Timeline for Should I estimate repeating tasks (besides Stories and Bugs)?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 29, 2017 at 19:53 | comment | added | Todd A. Jacobs♦ | @ppasler Daniel's previous comment is right. Burn-up charts show "work done," which is largely irrelevant to a time-boxed framework like Scrum which is most effective when dealing with "work remaining." If you're reporting effort expended as a first-class metric, you've got a process problem. See Consumed Story Points for some related analysis. | |
| Jun 27, 2017 at 14:02 | comment | added | Daniel | As for velocity, you don't have an even velocity. Every few sprints you can take on less feature development because you have to make time for these tasks. Your velocity is most valuable when you are showing how much progress you our making on building new product sprint to sprint, not how much work you do (this is the outcome vs output argument we so commonly hear in scrum) | |
| Jun 27, 2017 at 14:00 | comment | added | Daniel | I'm not clear what you mean on burnup charts. If you are using longer-term burnups (like 3+ months out) then you would need to work every expected release task in if you estimate them or reach one would just bump up the target line. | |
| Jun 27, 2017 at 7:43 | comment | added | ppasler | The point is, burn-up charts getting influenced by these tasks, that's why I thought about giving tasks SP values in the first place. This is needed to have a "kind of" evenly velocity. I want to keep the influence of these Tasks at a minimum. | |
| Jun 27, 2017 at 7:20 | history | answered | Daniel | CC BY-SA 3.0 |