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.

BRD, Requirements Document in Agile Scrum?

While comprehensive documentation is valuable, a working software is MORE valuable as per the Agile Manifesto. One of the myth about Agile Scrum is that it promotes no documentation. The fact is that documentation is certainly not a bad thing, but Agile suggests to create minimum required documentation.

So the question is where do you keep user requirements - trying to find something similar to BRD (Business Requirements Document) in Agile?

The answer is rather simple - "product backlog"! Product backlog is only place to capture all the user requirements and as we know these requirements are prioritized by product owner for each release, sprint and is called release backlog and sprint backlog respectively.

Pic: 1) Product Backlog, 2) Release Backlog, 3) Sprint Backlog

You may also want to check this post to learn more about difference between terms Release, Sprint.

Sprint velocity basis yesterday's weather - Agile (XP)

Ok, before we understand what is 'Yesterday's weather' in Agile, let me tell you that Yesterday's weather is not an agile scrum term but an extreme programming term. Some of Agile terms are used interchangably now a days, and this is one of the methods to estimate sprint velocity for upcoming sprint, so thought to cover this term.

Lets take this example -

if it has been raining yesterday in Delhi, then it's quite likely that it would rain today as well. It may not be 100% accurate forecast but still good enough to suggest someone carry an ambrella today.

In Agile, 'yesterday's weather' refers to last sprint's velocity. Development team may have been working at varying velocity in past sprints (20, 18, 25, 28) so one of the ways to estimate how many story points development team can deliver in next sprint is to check last sprint's velocity - this may not be the best way but can be called a best guess, or bet. So in this case, 28 story points would be the answer.

You may also find these related posts valuable in Sprint Planning section.

Is Scrum Master a Project Manager in Agile Scrum?

The straight answer to that would be 'no' - and I guess everyone who has spent 30-40hrs learning Agile Scrum would know this short answer, but let's understand why behind it and that is really important.

OK, lets understand why these two roles are NOT same -
1) Agile teams are self-organizing teams, so if you are PMI Project Management guru (aka PMP) you would know - Project Manager spends lots of time and energy in organizing these resources (developers, testers, analysts etc, and their tasks etc) so by definition, these activities are no more required (to a greater extent), so Scrum Master is not supposed to (and may not even know how to...) do resource management. Scrum Master is like a coach in Scrum Team not manager.

2) Scrum Master (also explained as 'servant-leader' in scrum guides) - is there to do specific job(s) - ensure scrum rules/practices are being followed, remove impediments, (and keep chickens (sounds unfamiliar? - read this) away from team but keep them happy). Project Manager on other hand is assumed to be master of all these - so this is actually similarity between these two roles - but Project Manager is expected to anyways be master of all these (e.g. ensure project management practices are being followed, remove hurdles/blockers, keep chickens happy...), but this role carries lot of other responsibilities as well, than just that.

3) Ever heard of WBS, estimation, gantt charts, critical path analysis? - that's what we don't do in Agile Scrum, but on other hand in waterfall, all these are termed as 'most important tasks for a project manager', and hence a Project Manager is different from Scrum Master. Even estimation is done by developers in consultation with Product Owner, and Scrum Master has little role to play there.

So in nutshell, the role of Project Manager is divided is Agile Scrum, and the tasks are distributed (by nature of Scrum), among all members of Scrum Team.

Further reading - I strongly recommend you to read a short and simple (16 pages) Agile Scrum Guide by Ken Schwaber and Jeff Sutherland.

Acronyms, Agile and Associations

Acronyms/Mnemonics in Agile and their associations -

Associations - 
DEEP - properties or characteristics of a good product backlog
INVEST - properties or characteristics of a good user story
3 Cs (CCC) - three critical aspects of a user story (or in 'plain english' - one of the many ways to write a user story).

Full forms -
DEEP - Detailed Appropriately, Estimated, Emerging/Emergent, Prioritized
INVEST - Independent, Negotiable, Valuable, Estimable, Small, Testable
3 Cs - Card, Confirmation, Conversation