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.

Re-posted from

About WinnipegAgilist

Steve Rogalsky - An agilist and team member at Protegra with a passion for agile and lean principles and practices. Green bar addict, agile player/coach, teacher, dad, husband. Email: steve.rogalsky at protegra dot com


No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: