Timeline for How to handle issues that are part of the backlog, solved in the weekend and are not part of current Sprint in Scrum?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 27, 2017 at 2:57 | comment | added | Vicki Laidler | Great answer. I wish I'd had this clear, comprehensive guide last year when I was dealing with a number of the problems you mention. | |
| Nov 25, 2017 at 17:54 | comment | added | Daniel | Very well-written answer. I think it's important to point out a few big anti-patterns I see in it though. Before I do, I agree that programmers like to program and they want to work on things they care about. That's the first problem - why is that not worked into the prioritization? Yes, business value should drive priority, but it shouldn't dominate it. Next, what you are describing is creating half-done code. You have code in your app that is untested and unreviewed for a period and that forces the PO's hand on prioritizing the rest of the work anyway. Feels very messy and underhanded. | |
| Nov 25, 2017 at 15:55 | comment | added | RubberDuck | I don't understand the downvote. This is a very pragmatic answer. | |
| Nov 25, 2017 at 14:07 | review | First posts | |||
| Nov 26, 2017 at 10:53 | |||||
| Nov 25, 2017 at 14:03 | history | answered | pft221 | CC BY-SA 3.0 |