Elicitation, requirements that survive contact with a delivery team, and the analysis that decides what gets built.
Business analysis in an agile setting is less about writing a specification and more about running the conversation that produces one, then keeping it honest while the work proceeds. This list starts with the mechanics of stories and backlogs, moves to the elicitation and research skills underneath them, and finishes with structuring an argument for the people who sign things off. It suits business analysts, proxy product owners, and anyone whose job title changed when their organisation adopted Scrum.
Cohn on the card, conversation and confirmation model, the INVEST criteria, and the elicitation techniques that produce a story in the first place. The clearest treatment of the mechanics you use every week.
Patton's answer to the flat backlog, arranging stories along the narrative of user activity so a release becomes a slice rather than an arbitrary batch. It also explains why the shared understanding a workshop produced keeps evaporating afterwards.
Four levels asking why, who, how and what, so every requirement traces to a goal and to an actor whose behaviour must change. Short, and it hands you a defensible answer when someone asks what you left out.
Adzic on illustrating requirements with concrete examples, refining them into a specification, and keeping a living documentation system in step with the code. Directly useful when requirements and tests drift apart between refinement and release.
Fifty short independent techniques covering creating, planning, discussing and splitting stories. Built to dip into when a specific problem shows up rather than to read front to back.
Elicitation goes wrong when you ask people about a proposed solution instead of about their work. Fitzpatrick gives you the questions that yield facts and a way of deflecting praise back towards evidence.
Portigal on the craft of the interview itself, covering preparation, rapport, silence, follow up and the synthesis afterwards. The complement to knowing which questions to ask.
Hall is direct about sample sizes, about when a survey is the wrong instrument, and about turning what you heard into something a team can act on. Written for people fitting research around another job.
Analysis has to end in a recommendation somebody reads and acts on. Minto's situation, complication, question and answer structure is the reason consulting documents land, and it transfers straight to a business case.