Differences in Documentation and Deliverables
One of the greatest differences of being on an Agile team for Business Analysts is the management of requirements. Analysts who are used to thick requirements documents or being the sole maintainer of such information within a requirements management software package will immediately notice the different approach to requirements elicitation, gathering, documentation and ongoing management.
Schwaber stressed that Business Analysts need to understand that they “come to play in a self-organizing team that communicates visually and verbally rather than by written documents.” While that doesn’t necessarily mean that there will be no documentation, the emphasis is clearly shifted to ensuring that the people who need to meet the requirements understand them rather than having a pristine document that may not effectively communicate the information to the implementers. The Agile Manifesto principle of “working software over comprehensive documentation” is used to ensure that just enough documentation is created and maintained. This does not mean that the documentation should be incomplete or shoddy, but it should be concise and as accurate as possible at any given point in time.
Instead of a requirements document, Business Analysts may be writing requirements in the form of user stories, or they may be maintaining lists of functions, features, performance metrics, or some other relevant item. While some Agile teams may adopt a standard for documentation, others will adapt their documentation to meet the current needs of the team. For instance, user stories may be written for all software functions to be built, but in some cases a supplemental ‘spec/details sheet’ may be created for certain stories if more information is required than can fit on a 5 X 7 card.
Furthermore the documentation that Business Analysts write is unlikely to undergo a formal sign-off process. While input and clarity is essential, Agile teams rarely are looking for an official approval before going to use the documentation. Some Business Analysts may find the lack of comfort knowing that stakeholders have officially approved written deliverables a little disconcerting. However, if the team and the stakeholders the team serves can build a level of trust that allows for ongoing engagement and collaboration, the benefits to accurately delivering to the customer’s needs instead of a potentially antagonistic approval process can help the Business Analyst adapt to the situation.
Some Agile teams may take an extreme view of the Agile principles and not see the value in documentation. Kohl stresses that Business Analysts shouldn’t “be bullied into producing shoddy work just because the Agile team isn't familiar with your skills and tools. If this happens, overcome it by demonstrating how your work is helping the team create value, and how what you are doing is consistent with the Agile Manifesto, and is not threatening the process the team is depending on.”
For instance, Gottesdiener notes that “Agile presents special requirements challenges. Current lore about representing requirements as user stories does not directly address non-functional requirements (e.g. quality attributes and design and implementation constraints). Sharp Business Analysts can provide crucial help in eliciting and analyzing those important requirements.”
Business Analysts and the Product Owner Role
In the Scrum methodology there are only two specialized roles defined in the team: the ScrumMaster and the Product Owner. The Product Owner is seen as the go-to person to understand customer requirements and is ultimately responsible for prioritizing the team’s product backlog. Given a Business Analyst’s involvement in requirements management in traditional projects, this role could be one that is filled by a Business Analyst.
Pichler sees product backlog management as an important task where Business Analysts can be heavily involved; however “this task should be a team effort.” Schwaber believes that Business Analysts can have “a solid career path to leave IT and go into being a Product Owner in the customer organization or product marketing.”
Whether the Business Analyst should play the role of the Product Owner can depend on their expertise. Cockburn believes that if the Business Analyst is an “expert in the operations of the business”, then being the Product Owner is a natural fit.
Pichler does note that in a Scrum setting “getting direct communication established is, for me, the right way to get things going in an Agile world.” As a result the need for a dedicated Product Owner can be diminished in terms of representing a customer or stakeholder group. Pichler also cautions against having the Business Analyst play the role of a ‘proxy Product Owner’. He considers this an ‘anti-pattern’ of functioning Agile team that can have negative consequences for all involved. Pichler describes this anti-pattern in detail in his upcoming book, Agile Product Management with Scrum.
Pichler recalls how in one company “the Product Vice President was too busy to be the Product Owner, so the Business Analyst stepped in as a proxy. But authority was ultimately with the Product Manager”. This led to a frustrating experience for everyone as decision making was delayed, communication lines were broken and the team did not have a clear vision for the product.
Gottesdiener believes that “the Product Owner must conduct a mix of strategic and tactical activities. This takes a lot of knowledge and many skills, and it consumes a lot of time.” Seldom does a single person have the ability to fulfill all aspects of this demanding role and as a result “many organizations turn to talented Business Analysts for help with the day-to-day, tactical decision making on their Agile projects. In other cases, someone who was formerly a traditional Business Analyst will work out the backlog items, suggest the priorities, and then obtain validation from the business Product Owner.”
Ultimately, the Business Analyst may be the best choice for Product Owner on a Scrum team, but it does depend on the environment and the other individuals involved in the process.
Other Activities Business Analysts Perform in an Agile Team
As noted above, Business Analysts may find themselves participating in other activities that they may not be accustomed to. In addition to writing user stories, Business Analysts may write acceptance tests, user documentation, or work with more technically-oriented individuals to help with documenting the system itself.
Because Business Analysts typically have strong communication skills, they can play an important part to help get the rest of the team get comfortable with its stakeholders. If other team members are new to Agile they may not be used to the open lines of communication between the team and outside personnel. The Business Analyst can help ensure that there is ongoing and meaningful two-way communication to help ensure the team is meeting the customer’s needs.
The Business Analyst can also help facilitate sessions within the team as well as with outside stakeholders. If the team is using Scrum then the ScrumMaster will manage the regular meetings a team holds (daily stand-ups, demos, retrospectives and planning sessions). As a team member the Business Analyst should look to support the ScrumMaster as needed and help identify potential issues as they arise to ensure the team is working as efficiently as possible.