Timeline for How do you reduce card size and limit scope creep in R&D tasks?
Current License: CC BY-SA 3.0
3 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 16, 2017 at 15:42 | comment | added | David Espina | I would say, no, too, but I have never cut checks for an R&D project that was "going nowhere." At some stage, you have to stop throwing good $ after bad. But that is different than a timebox. I think you're right, a timebox would be inconsistent with what you are trying to do in R&D. Time is already constrained simply by the $$ you have available. I think the OP is chasing the wrong issue. | |
| Oct 16, 2017 at 15:35 | comment | added | Thomas Owens♦ | As you move further from product development and closer to research, is there an advantage to timeboxing research efforts? Spikes exist to address work that requires research time. But Spikes (like many things in many agile approaches) are timeboxed. If you are building a product, it makes sense to eventually stop research and make a decision with some level of increased knowledge. But if you're doing research, maximizing knowledge is likely to be your goal. So is moving onto the next task after a timebox appropriate for something closer to research? I think that the answer may be "no". | |
| Oct 16, 2017 at 15:29 | history | answered | David Espina | CC BY-SA 3.0 |