3 ms·

You can tell that, but if you are 'researching' during the implementation phase, how the hell did you give an estimate on the task? I'm not blaming you, I'm jus

• mytailorisrich 2y ago
  If your high level story is to "implement a button that cancels the order when cliked", for instance, then this can be broken down into several taks, the first of which may be about reasearch and investigation. Even during the implementation phase you might hit an unexpected issue that will need to be investigated and researched. If you're trying to fix a bug then investigation and research may be the bulk of your time. The point is that tasks/tickets/stories and what you're spending your time on don't have to be only about typing code and it's perfectly normal to report as such. Regarding estimates, the issue in the real world is that estimates on incomplete data very often end up as commitments when told to project management. This is quite orthogonal with Scrum and is part and parcel of working on any project.
• Fire-Dragon-DoL 2y ago
  You could do the reverse, timeboxing it. Goal being to avoid spending excessive time on the task. Having a well defined amount of time for a research task makes sense, the business decides how much they want to spend. I'm against estimating every task, but I definitely provide a ballpark idea when a project will be delivered. Keeping a research task in check is important for myself too, otherwise I can go on for weeks.