Agile approaches are becoming more common for software development projects. This blog and several future blogs will discuss concepts important in agile approaches from the perspective of a business analyst. The first concept to be explored is collaboration.
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,
- Being part of the solution - May 1, 2012
- What’s the difference between ordinary and extraordinary… - March 14, 2011
- Lots of resources to learn about agile - May 10, 2010
- Agile and the BA – Part 1 - March 23, 2010
- Is It Really Tyranny of Best Practices? - February 20, 2010
- BAs are Bridge-Builders Instead of Bridges - January 25, 2010
- James Bond and Business Analysis - January 18, 2010
- Should the BA scribe at a team meeting? - August 4, 2009
- Why do we need detailed business requirements? - July 28, 2009
- Updated CBAP® Handbook now available for download - July 14, 2009