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

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?

1 answer

1 accepted

This widget could not be displayed.

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.

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?

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"

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Apr 22, 2018 in Jira Software

How-to setup a secured Jira Software 7.9.0 on Ubuntu 16.04.4 in less than 30 minutes

...PermissionsStartOnly=true User=www-data Group=www-data ExecStart=/opt/jira/bin/startup.sh ExecStop=/opt/jira/bin/shutdown.sh TimeoutStartSec=120 TimeoutStopSec=600 PrivateTmp=true [Install] WantedBy...

1,455 views 10 12
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you