5

Say I have a team member who is working on a story. While working on that story, s/he runs into an issue that could or could not be crucial to the completion of that original story.

Should the team member:

a) Go down the "rabbit hole" and see if s/he could solve the issue.

b) Write up another ticket for the issue and place it into the current sprint and start working on it.

c) Write up a ticket and pass over it for now, and see how long it can be swept under the rug during this sprint.

I'm leaning toward option C as it allows the developer to keep working toward the completion of the feature. But it still reports the issue.

Any thoughts? Which option would you advise, and why?

Sarov
  • 14,768
  • 5
  • 33
  • 62
Andrew Graham-Yooll
  • 153
  • 3

2 Answers2

6

Option A should just not be done; don't do any invisible work. If new work crops up in any form, document it. This is assuming it's not just a two-minute thing, of course, but if so then it's probably not worth talking about in the first place.

As for what should be done...

While working on that story, s/he runs into an issue that could or could not be crucial to the completion of that original story.

The answer depends heavily on whether that's 'could' or 'could not' - or, rather, 'does' or 'does not'.

If the new issue does not impact the completion of the original story, then it's just new work. Put it in the product backlog and notify the Product Owner. Option c, in this case.

If the new issue does impact the completion of the original story, then it is essentially an unexpected roadblock on the story. You obviously can't finish the original story until the roadblock is resolved, so the roadblock becomes higher priority. At that point, you can either negotiate with the Product Owner to include the new work in the Sprint while taking something else out or (much more traumatic) terminate the Sprint early and re-plan.

If you don't know whether or not it impacts the completion of the original story, then first order of business is finding out.

Sarov
  • 14,768
  • 5
  • 33
  • 62
  • Say this issue happens probably more frequently than it should. How could I prevent this from occurring in the future? – Andrew Graham-Yooll Jun 05 '17 at 20:32
  • @AndrewGraham-Yooll Simple/naive answer is to spend more time preplanning/investigating the story before the planning meeting. – Sarov Jun 05 '17 at 21:00
  • This is a good answer because it implicitly addresses the importance of the Sprint Goal in determining what work belongs in the current iteration, and what belongs on the Product Backlog as future work. – Todd A. Jacobs Jun 06 '17 at 05:52
1

I am assuming you are describing an edge case scenario. The way we work on edge case scenarios is by answering few questions such as :

1. Is it easier to fix this 'Inconsequential' issue now rather than later from a development perspective ?

Sometimes fixing an issue early, however inconsequential they might be for the final solution can save you from a lot of maintenance hours, especially if they are known unknowns. If you are answer is Yes, You should raise a new ticket with priority as 'Inconsequential'(or a similar status) and talk to your product owner and negotiate its priority for the ongoing or next sprint.If your answer is No, still raise the ticket with priority type as 'Inconsequential'.

2. Will the deployment logistics support an easier upgrade during next release ?

If your answer is Yes, then this will allow you to move this fix to the next scheduled upgrade. If you are answer is No, negotiate with your product owner and include the ticket in the ongoing sprint. It might push the limits in your team's capacity, however the learning from this exercise might also increase your team's capacity in future sprints.

3. Will not fixing this edge case impact the pillars of usability and stability of the solution ?

Even if the fix does not contribute to the specific problem you are trying to solve. If it hampers usability or the stability of the solution; this ticket's priority should be higher than 'Inconsequential'. Hampering architectural principles should be considered as major tickets, alike functional bugs. Hence if your answer is yes, bump up its priority and if the answer for 1 and 2 is also Yes, schedule it in current sprint.

alphadom03
  • 23
  • 4
  • In #3, you mean adding it to the current sprint, even if it affects burn down? Im all for it, I just don't know how to handle it in future cases where it may happen. Do I chalk it up to 'bad luck'? Do I see it as a symptom that the stories are not detailed/worked through enough? – Andrew Graham-Yooll Jun 05 '17 at 20:30
  • If you answered yes for all 3 questions, your architectural principles governing your product architecture is not strong enough to solve the real world problem. If this is a recurring problem and if the analysts are picking more such issues, it does not imply the stories are not worked through. It means that the backlog refinement sessions are not happening or is taken lightly ahead of the sprint with a fragile roadmap. – alphadom03 Jun 05 '17 at 23:33