Value Proposition of the Business Analyst on a Scrum Team

Show all

Value Proposition of the Business Analyst on a Scrum Team

It is important that we qualify that adding a BA to the Scrum team would create more benefit than not doing it.

›Agile Manifesto principles that shout “BA”

From the Agile Manifesto principles I find the following ones are most impacted by the involvement of a BA:

“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

  • BAs focus on mastering the skill of developing good requirements.
  • It makes sense to utilize professional BAs in an Enterprise environment where we can afford to leverage the skills of master roles.
  • Because the Scrum methodology was birthed out of the development world it stands to reason that developers would not appreciate the value add that a non-development team member like a BA or UxD/IxD would provide to the methodology. It stands to reason that they would assume that requirements are secondary to just developing something. We all know better.
  • Using a BA to develop visual user interface storyboard’s pre-Sprint and pre Development in the Sprint creates synergy, more efficiency, communicates clearer and is a cheaper task than the developer creating user interface. Also the product owner doesn’t have to wait until the end of the Sprint to get a clear idea of the user interface.

“Business people and developers must work together daily throughout the project.”

  • Scrum is unique in that it elevates the Dev resource to a level that allows them to interact with business users.
  • The primary benefit of this is that Dev can help the users formulate their ideas and solutions to problems better informed by having a trusted technology partner on-hand. The question of build-ability is better answered up-front.
  • The downside to this is that Dev resources are notoriously bad at interviewing skills and the elicitation process.
  • BAs on the other hand have a personality and a skill-set that is tuned to work as a go-between for the business and the technical resources. By involving them in a collaboration fashion as an add-on to the typical Scrum life-cycle, you have more efficient, quality throughput of “working together” between the business and development.
  • Another benefit of having a BA actually write the PBIs and the acceptance criteria, versus having a developer resource do that, is that the BA will ensure that it is written in a common style that can be understood by both business and technical resources. For highly technical content, the BA can separate out that section in the Acceptance Criteria under a Technical Notes section.

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

  • One of the biggest problems with Scrum is the lack of ability for the PO to stay ahead of the Sprint with fully qualified PBI lists that is properly prioritized and stories that are well formed.
  • Having a BA involved gives the PO a buffer to get a head of the DEV team slightly so that when the PO meets with the Dev team they have a more sustainable pace and experience.

“Continuous attention to technical excellence and good design enhances agility.”

  • Most scrum developers completely bypass technical design and as a result of lack of skill-set do not form fully expanded requirements / PBIs / user stories.
  • Adding a BA into the mix brings a greater chance of getting to the good and excellent. It is a quality add-on that elevates the team to a more mature position.

“The best architectures, requirements, and designs emerge from self-organizing teams.”

  • Nothing in Lean, the grandfather of Agile Scrum, dictates that you can’t do things better and more efficient. In fact, that is the point.
  • Mature, enterprise-level scrum teams are realizing that they cannot do without the level of rigor that Agile BABok outlines.
  • Instead of having worn-out developers try and “do more” with less and figure out how to get the level of rigor that is really needed in an Enterprise level organization, why not just bring the BA in at the outset and let them add the value that really only they can add to the team. This is what has emerged with other mature self-organizing scrum teams.

Some Value Propositions of a BA to Agile

What are some of the value propositions of a BA to agile?

Faster Cheaper Feedback:

  • I believe that the biggest reason that agile Scrum has gained popularity is because there is a shorter feedback loop (the Sprint) from the conception idea that comes from the business until the review of the actual product development. This allows the problem of products being developed that are not what the business envisioned to become a lower risk. The user experiences this benefit by looking at the tangible products of development – usually the user interface of the feature developed.
  • A BA can synergize and make that feedback loop even shorter by using user interface story-boarding modeling tools that don’t abstract the business user’s envisioning and create a pseudo-product that clearly communicates the user’s expectations to development.
  • What is great about a BA doing this is that a BA’s time is typically cheaper than a Dev resources time and their ability to create such artifacts is much quicker than a developers ability to do so in the actual user interface.
  • This doesn’t hamper a developer or UxD (user Experience Developer) from influencing and being a part of the creative process anymore than they are hampered currently. It just makes the feedback loop faster and more efficient.

Single Voice:

Much like other approaches, business analysis is central to the success of agile projects. Business analysis is necessary to enable a diverse group of customers to speak with a single voice. [3]


Without the analyst, real gaps occur:
  • Who looks at the bigger organizational problems?
  • Who identifies the underlying conflict between what management want (the Customer who pays for the software development, after all) and what the “Users” (a horrible term – but that will be the subject of another discussion) need in order to do their jobs effectively?
  • Who identifies the fact that there are (say) 1500 people who are currently doing their jobs in one way, and that after we’ve implemented the new software will need to significantly change their work patterns?
  • Who helps these people design new organizational procedures to ensure that the business continues to run smoothly as the changes are made?
  • Who identifies the potential lost business due to a poorly thought out customer interaction?

A BA is more People versus Technology Person, but still has the technology:

A BA is someone who understands how people behave and who can help the Customer come up with guidelines for the technology implementation to ensure that the resultant product works effectively in real-world use.

Business Analysts Contribute to Team Success: [2]

  • The de-emphasis of the importance of this role is one of the major gaps in many Agile teams today.
  • In many organizations the analyst role is hobbled – unable to effectively deliver the value they promise due to organization structure and lack of management support.
  • The business analyst needs to be seen as the customer advocate, part of the business-focused solution provision team, rather than a purveyor of technology.
  • Politically empowered, trusted and acknowledged for the perspective and understanding they bring, the business analyst should ideally report into a business improvement area, not into the information technology group.
  • In this structure the business analyst will be empowered to recommend changes with a clear focus on the business value, rather than being perceived as the “lackey of technology” as part of the technology group.

Customer Advocate to do UAT:

  • The BA is the best person to do initial UAT because they lived the requirements lifecycle through the development process and can best validate that requirements were met in the solution.
  • Product Owners typically don’t have time for this level of detail and need to focus on bigger picture things.
  • An analyst is used to detail.
  • Developers are not third party enough and QA is looking at things from a deeper different level – and could really use some help

Possible Objections ›

Scrum doesn’t use a BA and our experience has never used a BA on a Scrum team – why do we need one?

  • One doesn’t know what one doesn’t know. Scrum methodology has never tried using a BA and doesn’t put the role into play.
  • Most Scrum team-members who have deep scrum experience have never utilized a BA on a Scrum team.
  • It is very likely that most Scrum team members won’t know the value of having a BA because tthey’venever tried using one.
  • Lean, the granddaddy of Scrum, requires that we adopt a philosophy of continuous, incremental improvement – that includes the Scrum methodology as well.
  • I would suggest that one never change the methodology or process unless the change adds value and/or efficiency/throughput. By changing process without value validation one runs the risk of falling back into bad habits likely that look like their old water-fall approach. Adding a BA to a team definitely adds value and should be seriously considered.
  • Again from the Manifesto, “The best architectures, requirements, and designs emerge from self-organizing teams.” At many companies we have definitely proven the value of the BA skillset and resource. Self-organizing at your company means integrating BA resources and skills into the Scrum team.

The whole point of doing everything in the sprint is to get the synergy of the team working on the problem space and the solution – especially involving the Developers in the requirements formation. Having a BA and having them work pre-sprint would erode that goal wouldn’t it?

  • This objection comes from the manifesto point, “Business people and developers must work together daily throughout the project.”
  • I’m proposing that the BA is really an extension of the Product Owner business person on the team.
  • Product Owners are great but they don’t typically have the skill-sets of the BA and that skill set is sorely missing from most PO’s deliverables.
  • If we think about the BA as an extension of the PO then we aren’t violating Scrum principles to do pre-grooming of Sprint user stories prior to the sprint – that is the job of the Product Owner.
  • What we are doing is raising the quality level of the PO output to the Scrum team and ensuring that the PO function is well supported to have better throughput and responsiveness to the Scrum work life-cycle.

Some ways that most teams are different than the typical Scrum Model ›

  • Team members are not all co-located.
  • Many offshore Devs are not engaged real-time.
  • Enterprise multi-system dependency versus single platform SAAS model of most scrum implementations.
  • Greater than 3 Devs making the team larger than 6-8, a-typical for most scrum teams.

Suggestions for Utilization of BAs

Agree on definition of terms & roles that translate to what BA does:

  • User stories are nothing more than a textual version summary of one path of a use case.
  • Acceptance Criteria is nothing more than requirements – business and functional and it is the responsibility of the BA to define those requirements down to a functional requirement level of detail.
  • BA role most closely translates to portions of the PO role.
  • Scrum-Master is essentially the PM role.
  • DEV and QA roles do not differ at all from their Scrum definition
  • UxD/IxD are Dev roles that also have some user business and user functional definition responsibility. It is best if their business/functional work is done post BA taking a shot or in close tandem with BA for purposes of:
    • single source of truth
    • not bothering the business SMEs with the same question sets
    • and to have synergy versus tension

Agree that the BA deliverable is not a Word document

  • The BA Deliverable is not a Word Document that is tailored to really fit water-fall only projects.
  • In the manifesto this meets the goal of, “Working software over comprehensive documentation”

Consider BA as an internal team PO, or “executive officer” to the PO

  • Could act as proxy to a busy PO.
  • Remember that a BA’s #1 goal is to facilitate the communication and understanding between business and technical resources.
  • The BA is different than the PO in that they don’t decide Product Visioning and decide PBI direction and genesis.
  • They may do prioritizing and maintaining of the backlog for the PO, with the POs review and over-ride if the PO so desires.

Pre-Sprint PBI Grooming

  • Let the BA work essentially in the Sprint 0 and pre-Sprint on grooming user stories (their work is not constrained to be within the Sprint as is the case with DEV, UxD/IxD, and QA resources) with the goal of:
  • Ensuring well-formed user stories for the PO, pre-grooming with the Sprint team,
  • Ensuring stories work in coordination with the Epics,
  • Providing any modeling techniques that would help communicate the story, validate the assumptions or illustrate the problem to be solved,
  • And providing context for the story in relation to other user stories, hopefully with modeling.

Sprint Tasking:

  • Create in-sprint tasks for the BA work.
  • Cause the DEV tasks to be dependent and to not start until BA tasks are complete.
  • Suggested Tasks per PBI item:
  • BA: Refine PBIs/User Stories/Document Functional Requirements (Acceptance Criteria) (2 hours)
  • QA: Study and Review Requirements
  • DEV: Study and Review Requirements
  • BA/DEV/QA: Team Review of Requirements (3 hours – 1 hour per person)
  • PO/DEV/QA/BA: Review (2 hours – 30 min each)
  • Requirements Support (2 hour)
  • Requirements Check/UAT at the Sprint level (1 hours)
  • Requirements Check/UAT at the Release level (1 hours)
  • Identify impacts to roles/features and update documentation (1 hrs)
  • Preparing Customer Communication (at the Release level) (1 hr)
  • Training Documentation updates (1 hr)


  • Have the BA work within the code management system (ie. TFS) sprint PBI items to document requirements versus using some other “source of truth.” BA does not create a document. They do fully utilize their modeling techniques and tools. Level of detail and quality is the same for the BA as in water-fall or other modes.
  • Allow the BA to use other modeling tools but they must generate HTML or picture (jpg, etc.) outputs that can be attached or referenced directly out of the acceptance criteria of a PBI.
  • Use Urban turtle or some other Product Backlog Item List transformation tool that allows one to get a visual of the Sprint work process – prioritization of PBIs, Sprint Tasks, etc.

Modeling Context:

  • Ask that the BA create at least 2 contextual models that live independent of the Code Management PBI list.
  • User stories: BA should create UML visual diagram of users and their goals. Each path of the UML goal “use case” should be expanded to include the user story summary and link to the Code Management Managed PBI item.
  • User Interface contextual model: BA should create a navigable storyboard of the screens and paths that users can take as they are built out by the Sprints.
  • Other Optional Models: System View, Requirements Wiki view, Data Model View, etc.