Atlanta Scrum Users Group Message Board › where/how does a traditional BA fit into agile/scrum?

where/how does a traditional BA fit into agile/scrum?

user 11422805
Atlanta, GA
Post #: 2
I'm a PM learning about scrum.

in our environment, dev tends to go straight to business for questions instead of through BA, it's how we reduce our feedback cycle time.

do traditional BA roles still have a place in Agile? How should they be utilized?
A former member
Post #: 17
I recently posted an article about this. In short, a traditional BA role does not fit well. However, a redefined BA role that is allowed to evolve with an Agile process can be of very high value to a team. See the following:

The Agile Business Analyst
Maryli M.
Atlanta, GA
Post #: 1
Hi Bob,

I'm a Sr. Business Analyst (CBAP) and also a PM (PMP). I recently took the course & got certified as a Scrum Product Owner.

Over a period of 20+ yrs my role as a BA has gone from "what's that" to an increasingly tightly defined description.

I believe a person with true BA experience: understands business problem, can do analysis's such as root cause & gap, can gather & product concise and relevant requirements, etc., along with having an good understanding of what the business considers project mgmt can do an excellent job on a scrum team.

A BA can help both the business & the development team stay focused on meeting the business needs. We should be the Product Owner by proxy. In other words empowered to act on behalf of the Product Owner. What's a Product Owner to do if she/he has 10 projects in the queue and day to day operations to run?! I've been a proxy many times in my career as a BA.

I see the current & PMI certified roles of Project Mgrs gaining less relevance as teams increasingly become more self-directed & collaborative. A little bit of PM work by the Product Owner, a little bit of PM work by the Scrum Master - all without compromising an environment of self-accountability will go a long way.

That said I consider the role of a Program Mgr becoming more relevant as a way of ensuring the business needs are being met across multiple projects - regardless of whether they are scrum or trad'l projects.

Maryli Marcos
BA On-the-Go!

user 11422805
Atlanta, GA
Post #: 3
This is my first attempt at running an Agile process (formally). It is an upgrading/merging of an old VB6 app to an existing .Net app.

So far, we all learned about the business processes, had our first brainstorm session and generated 20+ User Stories, and planned for our 1st Iteration. Let me know what you think about my plan for my BA (his first time as well):

1. Communicate to the Business Owner, Business Sponsor, Power Users our User Stories
2. Explain our Iteration 1 plan
3. Collect/generate new User Stories to present to the group (Product Owner, Devs, DBAs)
4. Work with the Power Users to develop Scenarios for Testing on User Stories

What do you think?


I also see the role of pure PM & pure BA becoming less and less relevant as Lead Developers become Product Owners and individual developers own their process and talk directly to the business/power user.
A former member
Post #: 18
If your Business Owner, Business Sponsor, Power Users, Developers, DBAs, and any other part of the cross-functional team it takes to move work from concept to customer were not part of writing your User Stories, you're sacrificing the key benefit of User Stories as a requirements gathering and release planning activity. There's a discovery and synchronization process that happens in the course of the team brainstorming on the requirements.

Lead Developers are not Product Owners, unless you're writing a tool that's only for the use of the Scrum team itself. Either your Business Owner or Business Sponsor should be your Product Owner, based on the limited information I see here. If you are not already intimately familiar with the following books, I highly recommend you obtain and absorb them as soon as possible:

  • Cohn, Mike. 2004. User Stories Applied For Agile Software Development. Addison-Wesley.
  • Cohn, Mike. 2006. Agile Estimating and Planning. Prentice Hall Professional Technical Reference.
  • Poppendieck, Mary and Tom Poppendieck. 2003. Lean Software Development: An Agile Toolkit. Addison-Wesley.
  • Schwaber, Ken and Mike Beedle. 2002. Agile Software Development with Scrum. Prentice Hall.

A former member
Post #: 19
For any of you attending DevNexus here in Atlanta on March 8-9, one of my talks there will be User Stories: Agile and Lean Requirements. I'll certainly be covering insight relevant to this thread in that talk.
A former member
Post #: 20

That said I consider the role of a Program Mgr becoming more relevant as a way of ensuring the business needs are being met across multiple projects - regardless of whether they are scrum or trad'l projects.

Maryli Marcos

You might enjoy Luke Hohmann's stuff on Agile Product Management at Enthyosis; he is excellent. The classic PMI Program Manager role maps roughly to his Product Manager role in Agile Product Management. As you point out, a Product Owner with a portfolio of 10 products could hardly manage the tactical aspects of a Scrum Product Owner role, but Product Managers certainly fit there.
user 11422805
Atlanta, GA
Post #: 4
I went through the Cohn 2006 book, will look into the 2004.

one of my challenge is most of the case study/readings i've come across deals with the Software Vendor type scenario, I'm having a hard time translating that into our internal organization.

We are an in-house dev team creating custom Order Management System and Maintenance System for our Business. So our "Owner/Sponsors" are Business Leaders, but our "Customers" are end-users that interact with various part of the system. Not to mention they are all over the country. It was hard enough for me to pull together the BA, Devs, Leads for the User Stories walk-through. Unlike a game example by Cohn, we have customers with specific needs and do not care about the others (ex: our application is broken by 3 major group of users: data entry, accounting reporting, management reporting)

My approach now is to walk through User Stories specific to each segment of interest: (Owner, Devs, BA, customer[1 type at a time].

Does that make sense?
user 87365412
Atlanta, GA
Post #: 7
I think including a business analyst in agile methodology is not very essential. In fact it could delay the feedback time.
Powered by mvnForum

Our Sponsors

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy