How to know if Agile is right fit for project or not?

One of the common question I am asked is, How do I know if agile is right fit for my project or not?

While there could be multiple factors influencing this decision, here I am reviewing the top 6 points that shall help you make a decision -

1. Team's location - well, while many would debate on this, but it is not that easy to run agile projects if team is spread across multiple locations/sites and in some cases floors. If you are considering "scrum of scrums" scenario, you may have those scrum teams across multiple locations/sites but 'one scrum team" should ideally be co-located.
2. How urgent the changes are - If changes are urgent, frequent, only model that could save you is "agile", so don't look further,, go for it. It is in the core of agile to be able to support business agility.
3. How clear the requirements are - Sort of connects back to the point #2, if the requirements are not clear upfront (well low level), so this would mean that frequent changes, so agile is the model to go for. 
4. Can it be sliced into smaller usable chunks? - Agile demands the work to be broken down into smaller chunks, and each of that chunk should be "usable" some way. If that's not viable, agile might not really fit as you would end up with large chunks of work that would take several days to finish, making it difficult to adapt to frequent changes if need be, and further taking longer to demo or time to release to end user.
5. Access to PO/users - Agile needs access to Product Owner or user quite regularly (actually PO), and if no one person can take charge of it, agile just won't work. You need someone who can write requirement statements (aka user stories), help groom the stories that development team can understand and implement.
6. Process v/s project - repetitive or new endevour? - Of course, go back to the definition of project - is it really a project or a process, if later, head elsewhere, it is not a candidate for agile.

List doesn't end here, but hope this helps get broad idea to start with. Happy to hear your views.

Impediment v/s Bug - are they same or different?

Let's understand what is impediment and bug in Agile Scrum. First of all they both are not same, they may be distantly related in some special situations but they are different.

Here are the basic definitions:
An impediment is a situation that is stopping/blocking the completion of work.
A bug is referred to a defect or issue in the work product.

On side notes do you know that the word "bug" was used to indicate an actual bug (fly, moth) on a circuit board causing a short-circuit or other problems. You can read more details here - http://theinstitute.ieee.org/technology-focus/technology-history/did-you-know-edison-coined-the-term-bug

A defect would typically NOT block the completion of work, though in some situations a defect may impede work and also be am impediment at same time. For same reason, a defect would relate to implementation of a work item (user story), where as impediment would block one or more work items (user stories).

Defect and impediments are tracked seperately in defect tracker and impediment tracker. Bugs would eventually be prioritized and added to product backlog and re-prioritized by product owner. Impediments would never be added to product backlog, but resolution of an impediment may be taken out as spike; if some research work is involved and/or a major bloker to work.

While bugs can be identified during development activities (coding, testing etc), and impediment would typically be identified during daily scrums. The scrum master is responsible for helping resolve these impediments to improve team productivity.

Theme, Epic, Story, Task, Feature

Theme, Epic, Story, and Task are Agile Scrum terms, whereas 'Feature' is a term is not so often found in Scrum handbooks (probably introduced by some eager minds).

1) Theme is logical grouping of stories
2) Epic is just a large/big story - that needs to be broken down in smaller stories
3) Story is a story (explained elsewhere), that is broken down into tasks to be worked upon by developers as per agreed 'definition of done'

In terms of size - Theme and Epic may be of different sizes, rest would always be in this order (from large to small) - Epic > Story > Task
So technically, only these two combinition are possible (just in terms of size as theme and epic are not comparable - if anyone is interested) -
1) Theme > Epic > Story > Task
2) Epic > Theme > Story > Task

Sprint Zero v/s Spike

Lets understand this in three easy steps -

1) Sprint Zero (also called as Iteration Zero) is not same as Spike. Spike is a 'story' and a Sprint may have one or more stories in it
2) Sprint Zero is usually done/planned/executed to perform some research or initial work that is required beefore you start First Sprint (also called as Sprint One, Iteration One)
3) Any Sprint may have one or more stories (also called as User Stories), so the Sprint Zero may be planned if there is a need of Spike (some research work etc.)