Here are is a summary of our conversation:
- How many BAs can articulate the goals and objectives of their company, team, or project? Start here if you cannot.
- Even if you are able to articulate the goals and objectives - can your team? Without understanding the project goals and objectives the team doesn't have enough information to help them make decisions about scope and priorities and often makes decisions based on 'Is this helping somebody?' which can increase the scope of the project.
- BAs can help facilitate the alignment of priorities and goals - enabling the business to speak to the development team with one voice.
- Facilitate requirements and a common understanding of the proposed system through inclusive modeling techniques (eg. user story maps, silent brainstorming, product box - see more here)
- Facilitate the acceptance of change (rather than the restriction of it).
- BAs don't do any less analysis, but they will end up doing less documentation. This reminds me of this tweet:
“Documents we write communicate our good thinking. You can write one without thinking. You can communicate good ideas without a document.” – Jeff Patton (Jan. 19, 2011 - twitter)
- As a BA, if you need to create a document, it will more likely be after the story is complete rather than before creating the story. Some additional guidelines for documentation on agile projects can be found here.
- Collaborate with testers who share many of the same concerns about priorities, goals, scope, and requirements.
- One thing that doesn't change is the need to work with the business as any software produced by the team may change the business processes. Even with iterative delivery, there will be adjustments to be made.
