Why the best BSAs are outsiders
BSAs stand alone, beset on all sides by opinions, biases, and agendas. Always agendas.
BSA have always been outsiders, leather jackets not required.
“It’s no secret in Agile development that BSAs¹ were not included in the original definition of the Scrum team,” says Kristin Arrayn² a long-time tech blogger and world-renowned ‘Scrum guru’. Arrayn made a name for herself by advising some of the top tech companies in post-bubble Silicon Valley when Agile development was first catching on, and she has been speaking and blogging about Scrum and advising Fortune 500 companies ever since.
“From the very beginning, BSAs felt like outsiders, interlopers. At the time, we didn’t understand that this tenuous relationship with the rest of the team would be one of the keys to the success of the BSA role.”
BSAs became a key role on large projects because product owners became quickly overwhelmed. Arrayn explains: “On a small team, a product owner can gather requirements by observing real users and conducting design workshops with SMEs³, and then still have time to write the user stories, develop process flows, and shepherd the stories through each sprint. But on a larger project, the workload precludes one person from doing all of that. Thus, the BSA was born, or rather, hired.” Arrayn has been a proponent of BSAs on Scrum teams for over a decade, back when anything outside of strict adherence to Agile principles and the Scrum framework was considered heresy.
BSA responsibilities; nothing to SMEs at.
BSAs are typically responsible for three areas in Scrum development: feature design, user story ownership, and contributing to OCM⁴. Let’s look at them one at a time.
- The goal in feature design is to understand the business problem, need, or goal as clearly as possible, so the most effective and efficient feature with the best UX⁵ is developed. To do this, they help the product owners conduct design workshops, interview current or potential users, and observe them working.
- User story ownership involves writing the user stories, developing all of the reference materials and artifacts, and shepherding the stories through each sprint. The key here is to successfully communicate and collaborate with everyone.
- Last is contributing to OCM in the form of documentation, the development of success metrics for adoption, and conducting UAT sessions⁶. People don’t often understand the connection between OCM and UAT sessions, that UAT can be a catalyst for adoption. If you get your champion users to try out the product early on — and they like it — then the rest of the users will hear about it and be much more open to the OCM training and communications later on. UAT is not to be confused with ‘Showcases’ which are strictly OCM, and often involve a lot of hoopla⁷ and shows involving dogs and ponies.
Of course, as the Scrum guru of Silicon Valley, Arrayn has a more philosophical way of describing their work: “The beauty of a BSA is the ‘S’. This is not some run-of-the-mill BA⁸ who spends their days gathering requirements and documenting specifications in massive files for an ungodly and unwieldy waterfall project. No way. The ‘S’ here means they are on the Scrum team, collaborating with developers, haggling over story points, deciding on the testing scope with SQA⁹, and developing all sorts of useful artifacts and reference materials that would astound and possibly frighten the average BA.”
It’s commonly understood that the duty of BSAs includes creating not only the design-focused mockups but also the more technically-focused field configuration documents, source-to-target mappings, and integrated user- and system-based process flows.
The ‘A’ is not just for Analyst.
Those who have spent time with Kristin Arrayn know that when she is winding up to share something she believes is irreverent or even defiant, she gets a particular gleam in her eyes. She has that gleam as she tells me, “Now we get to the ‘A’. Yes, it stands for ‘Analyst,’ but I posit that another word that begins with ‘A’ fits better, due to the toughest part of the BSA’s job. To be a good BSA you have to be capable, self-possessed, and just enough of a know-it-all to push back against anyone on the Scrum team. After all, the BSA owns the story, not the product owner and not the engineer. The BSA has to stand up to the agendas of both of these very powerful forces for the good of the product. In other words, sometimes the ‘A’ stands for ‘asshole.’”
As hyperbolic as she can sometimes sound, Arrayn has a point. BSAs aren’t on the business customer’s side. And they certainly aren’t on the engineer’s side. Arrayn says it best: “BSAs stand alone, beset on all sides by opinions, biases, and agendas. Always agendas.”
What and How: two things product owners don’t own.
The BSA-product owner relationship is fraught with strife and contention, and that’s how it should be, says Arrayn. “The product owner works for the business customer. Their job is to represent the interests of a business group. Keep in mind, this is a group that holds the budget and thinks the money gives them carte blanche to ask for and get whatever they want. Now, that may be true, but the how, that’s a collaboration among the product owner, the BSA, and the engineers.”
Those who know Silicon Valley are aware of this reality. Most product owners are notorious for coming up with exactly what they want. So it’s a good BSA who knows to look for the why, and to keep digging until the why is clear.
Arrayn explains: “The product owners may think they know what should be built because their responsibility is the vision. But let’s talk about ‘vision’ for a second. Does vision mean, ‘I want four buttons along the top, two panels in the center and a column of tiles down the right?’ No way! To me, ‘vision’ means: ‘I know what goals we are trying to achieve, what problems we’re trying to solve, and the current experience of the users.’”
According to Arrayn, the biggest mistake a product owner can make is to tell the BSA and technical team exactly what to build. “It’s like climbing up onto the scaffolding next to Michelangelo and telling him how to paint the ceiling of the Sistine Chapel. If the product owner has suggestions about how the product should work, that’s great. But they’re only suggestions.”
Roll over engineers, and let UX take over.
Once the BSA understands the real vision, they can think through options for creating a feature with an optimal user experience. A key factor in that process is talking with the engineers and testers.
“Engineers are just as bad as the product owners, in their own way,” says Arrayn. “Engineers think that just because BSAs are more technical than product owners, they can pressure BSAs into developing a feature in the laziest way possible, from a technical standpoint. It’s not that engineers are bad at judging good UX, it’s that they are undeniably lazy. They try to sell it as ‘working smarter’. They’ll say that simple logic means there’s less logic to break, which over time equals reduction in maintenance costs. But the truth is, good UX often requires more complexity.”
The gleam returns to Arrayn’s eyes when she finishes the interview with her infamous flourish: “‘Maintenance costs’ are just a smoke screen. Seriously, who cares about maintenance costs, if no one is using your product because your UX is the software-equivalent of going to the DMV¹⁰!”
- BSAs: acronym for business systems analysts. ↩︎
- Kristin Arrayn is a fictional character constructed from an assortment of real life ‘Scrum gurus’. ↩︎
- SMEs: pronounced ‘sm-eez’, acronym for subject matter experts. ↩︎
- OCM: acronym for organizational change management. ↩︎
- UX: acronym for user experience. ↩︎
- UAT: acronym for user acceptance testing. ↩︎
- Hoopla: excitement surrounding an event or situation, aka hype; not to be confused with the eponymous digital media service company. ↩︎
- BA: acronym for business analyst. ↩︎
- SQA: acronym for software quality assurance. ↩︎
- DMV: acronym for sadness. ↩︎