Organizations that are successful implementing agile approaches typically agree to support one main Agile Manifesto principle which is to value ‘individuals and interactions’ over ‘processes and tools.’ Agile is not a departure from principles that BAs have always embraced. We absolutely agree that it is difficult to elicit the best requirements without direct interaction with the domain subject matter experts and developers!

One major principle of agile is collaboration. Agile employs team collaboration in a variety of ways. First in agile approaches complete visibility is necessary. Whether the team works in a single war room or virtually using a SharePoint site, visibility into the progress of the project is a critical element. This really helps eliminate miscommunication around what is being worked at any given time. Additionally each agile project uses a prioritized requirements list to keep clear and visible the order that requirements must be worked addressed (in Scrum this is called a Product Backlog). Led by the product owner (project sponsor, product manager or key domain SME), everyone on the team participates in determining how many of the prioritized requirements will be included in the upcoming iteration.

Requirements are developed using collaboration. These requirements, often called user stories, will be briefly described at first on sticky notes or index cards (this can be done virtually) and they get detailed through more conversation with the users or user reps when the requirement is to be coded. Early user acceptance testing, and product demos (again another collaborative activity) really help everyone on the team understand whether the requirements are being correctly translated. Failing requirements are visible early in the project rather than waiting until the end of the project lifecycle during user acceptance testing on a traditional, plan driven project to find serious issues.

One more collaborative technique is the daily stand up meeting which many agile projects employ. This is a quick meeting with the entire team to ensure that everyone has visibility about the progress of the iteration. Project issues are discussed to inform everyone on the team and bring focus together to solve them quickly. In addition, everyone knows what each person is going to be doing on that day and how they will work together.

You may be asking what elicitation techniques a BA would use on an agile project. Interviews and facilitated user story workshops are most common but observation, document analysis, surveys, focus groups and prototypes are also common. Early user acceptance testing will be used to confirm that the requirements are correct.

BA’s may perform elicitation activities prior to the Iteration planning. This is sometimes referred to as Iteration zero (0). Again the key concept here is to make sure the business people or users are engaged as much as possible throughout the agile lifecycle. Compared to traditional projects the level of requirements detail known prior to the start of the iteration is less. It is on a smaller scale and typically requires fewer analysis techniques due to the tight timelines. One risk the BA faces on agile projects is that during the iteration if the business people are not available, the BA may need to represent the business and make requirements decisions. To do this the BA must have a deep understanding of the business. It is highly recommend that the BA work closely with the business to make available the appropriate SMEs during the time user stories are being detailed and tested for confirmation.

Agile and the BA – Part 2 will discuss how a BA can best be prepared to work on an agile project. I hope you will share your comments, experiences and concerns about agile projects. Collaboration works!

All the best,
Angie

User stories are brief descriptions or phrases written on an index card called a story card. They can be a great starting point for analysis because they are easy for users to describe and easy to document. They give an analyst or developer who is new to the business area examples of the type of work that is accomplished by the business. They also can be used to develop initial high level test cases.

The limitations of user stories are easily seen from the strengths above. They are not detailed and only describe a specific business transaction or situation. The number and choice of stories determines how well they, as a group, cover the scope of the business area. They do not formally call out data needs, business rules, or include consistent definitions.

For projects where user stories are dictated as the preferred requirements deliverable the experienced BA will be able to use them to drive down to detailed business and functional requirements which will complete the picture.

Tell us what you think!