nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

What to do when running into a potential rabbit hole in a story?

Andrew Graham-Yooll

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

Should the team member:

a) Go down the "rabbit hole" and see if he/she 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.

Im leaning toward option C.

Any thoughts?

And additionally, what if he/she runs into a story/bug that could be nice to fix but is not in the current sprint? Which option would you advise?

Accepted answers

Nic Brough -Adaptavist-

A is by far the worst option, as you don't know how deep the bunny has dug, so all of your estimates, velocity and planning could go out the window

B(1) is better, because you're at least tracking it properly, but still has the same problem of throwing all your numbers out.

B(2) might be a slight improvement, and feeds into C - raise it as a "spike" - a piece of work that is not dealing with the bunny hole, but at least dropping some stones into it to get a feel for how deep it is (the output of a "spike" is a new story or task with a full estimate and dependency notes if needed)

C is probably the best answer - it's new work you didn't know about, so it should go into a future sprint. Quite possibly right at the top of the list, but it should be planned like any other story, otherwise you are bringing new work into the sprint.

Of course, this can still cause problems. Your blocked story is not going to get completed in the sprint. You may suddenly find that because you're blocked on that, you've got significant spare capacity (at that point, it may well be worth doing the "spike", and then drawing other work into the sprint). It's going to throw out your numbers whatever happens (unless you had over-committed to the sprint). You might have a critical need for the original story to be done before you can move forward, in which case, you should probably re-plan the sprint and bring the new issue into it.

All comments

Nic Brough -Adaptavist-

A is by far the worst option, as you don't know how deep the bunny has dug, so all of your estimates, velocity and planning could go out the window

B(1) is better, because you're at least tracking it properly, but still has the same problem of throwing all your numbers out.

Andrew Graham-Yooll

Hey thanks Nic! This seems reasonable. As I am pretty new to implementing an agile development into a project, what are the potential ramifications to re-planning a sprint that is currently in progress?

Nic Brough -Adaptavist-

It has a tendency to destroy your velocity estimations, and if you do it, it is well worth involving the stakeholders and product owners so that they know what you're changing and the reasons for doing so.

It is all about the communication though. If you can point at a sprint and say "it went wrong because a bunny dug a hole and we didn't know how many carrots we'd need to get it out", that's a lot better than "your thing is delayed now because of something we didn't tell you"