Tuesday, August 9, 2011

The role of a business analyst in agile

I ran into Kevin Brennan tonight at #agile2011. I was glad for the chance to talk to him because I've received quite a few questions from BAs in Winnipeg about how their role will change when they work on agile projects and Kevin has been doing a lot of work with the agile extension to IIBA's BABOK.

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.
Plus, here are a few more that I thought of after our conversation:
  • 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.
If you have others to add or even disagree with some above - please comment or find Kevin or myself during the conference and we'll chat.