›Agile Manifesto principles that shout “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.”

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

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

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

Some Value Propositions of a BA to Agile

Faster Cheaper Feedback:

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]

Gaps[1]:

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)

Tools:

• 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.