One of the main characteristics of Agile Business Analysis is the use of “lightweight” techniques. The very nature of Agile analysis which emphasizes customer collaboration, working software, individuals and interactions, and responding quickly to change implies that certain techniques fit the bill more than others do. This does not however, imply that BAs cannot make use of alternative techniques on Agile Projects. Here’s a list of techniques every Agile BA should know about:
1. Retrospectives – A retrospective presents an opportunity for continuous improvement, which agile teams capitalize on through the evaluation of concluded iterations. It’s a meeting where team members discuss the ways in which the software product and the processes involved in its development can be improved. Questions like these are common: What did we do right? What did we do wrong? What actions can we take to improve the next iteration? BAs also have a unique opportunity here to gain feedback on the quality of requirements elicited. Though more requirements may emerge after the retrospective, its main objective is to improve current ways of working. The 4 Questions” of a Retrospective and Why They Work provides an interesting outlook on retrospectives.
2. Personas – The problem with user types or user roles is that they are generic and can easily conceal the motivation or real desires of system users. For instance, it’s easier and tempting even, to use words like user, customer or support staff…What if you could add some real depth to these roles and breathe life into them? This is where personas come in. They represent fictitious persons and their motivations for using the system.
Creating personas like this can help the agile team connect with people of different needs, instead of faceless user groups. The more connected the agile team is to the idea of how a real person would use the system, the better the software that will be delivered.
3. Backlog Management – The backlog is a repository of requirements that have been arranged based on priority. It determines what activities the agile team will be engaged in and outlines the order in which those activities should be performed. This repository has to be constantly managed to ensure that the activities needed to fulfill each item in the backlog are identified, outlined and prioritized before the next sprint.
4. Workshops – Workshops are a critical element of agile team management. They are held to deliberate on requirements, discuss priorities and identify any issues that can prevent the team from moving forward. Read more on Organizing Effective Requirements Workshops: Before, During & After
5. MoSCoW Prioritization – This is used to prioritize user stories; it can be used to examine the relative importance of implementing one user story (requirement) over another. Read more on MoSCoW : Requirements Prioritization Technique
6. User Story: This is a combination of a requirement, the user that benefits from the story as well as the acceptance criteria that determine whether or not the story has been accurately implemented. Read An Overview of User Stories
7. User Story Mapping – A map that links all the user stories together to ensure they come together as a cohesive whole. Story maps can indicate the relationship between user stories, a process flow or may link stories to larger activities. A user story map is also a means of achieving requirements traceability on agile projects and viewing the entire system functionality at a glance. It is often displayed on-screen during release planning sessions.