I hadn’t seen or talked to Dr. BA in quite a while. I used a combination of ChatGPT, geofencing, behavioral analytics and dumb luck to locate him in a lecture hall on a college campus in the Midwest talking to a handful of enrapt students. He looked the same as I remember him from years ago as he strutted around the front of the room making marks on the white board behind him as he walked by and pointing to the students in the front row as though leading an orchestra. Even his vest pocket watch hanging in two pockets of his knit vest seemed to be the same even though the vest itself now was tethered by only one button. I only saw the last few minutes of his lecture, not even enough to determine the topic, but likely it has to do with business analysis, although he mentioned the word ‘Agile” several times which made me wonder. The students were dispersing within minutes of my arrival and left the Good Doctor to me. He recognized me at once and the first words out of his mouth to me after years of absence were: “You have questions for me?”
He adjusted his Einstein glasses on his nose and stared over them at me like an eagle inspecting his prey.
Taken aback, I blurted, “Well, yes. I actually do have questions. That is what I am here for, as always.”
“I’ll put your questions on the backlog and I’ll get to them as soon as possible,” he replied.
“You have a backlog?” I was surprised since Dr. BA seemed to be from generations past and wouldn’t be up on the Agle community vernacular.
“Of course, doesn’t everyone,” he replied. He pointed to a list on the white board on the side wall. It covered three sections and every item ended in a question mark.
“Well, how long will it take to get to the top of the backlog and get these questions answered? It looks like a terribly long backlog.”
“We’re not talking Baskin Robbins in the summer, here. I will just put you at the top of the backlog.”
“You can do that?”
“It’s my backlog. We go way back and you went out of your way to find me, so it is the least I can do. So, what is the first question?”
I read from the clipboard I had with me which had questions from business analysts:
My boss is from the old school and he keeps talking about our ‘requirements repository’. We are trying to do agile, specifically Scrum. Are the user stories the requirements repository in Scrum? What should I tell him?
Dr. BA smiled and responded in his inimitable scratchy voice:
The only "repository" (or place where requirements are kept) in Scrum is the Product Backlog. The user story is not a repository of requirements, nor is the product backlog a collection of user stories. In fact, user stories are not requirements at all. They are merely statements about things we want to remember to talk about which might become requirements.” Dr. BA adjusted his glasses and stared at me over the top of the wire frames, “Or not. Requirements are the results of that discussion about the user story between the developer and the user or stakeholder. Those requirements may be placed on the backlog or, to get back to the question, put in the repository.”
He looked at me with raised white bushy eyebrows indicating that he was finished answering the question and I should be satisfied with the answer. I thought it best to go on with the next question since it was somewhat related to his answer.
“We have another question from another business analyst about requirements classification, and I’m going to paraphrase here. Basically, she is asking whether we need requirements classification for user stories, and if we do, how does one go about classifying user stories, and do we use the same requirements classification that appear in all the books. She's talking about “solution requirements”, “stakeholder requirements”, and so forth.
Dr. BA looked bemused. He responded:
"Requirements classification" is a process specifically for traditional non-agile approaches to product development. User stories are statements of functional needs and are decomposed into requirements and therefore are not classified as anything. The concepts of 'solution requirements", "stakeholder requirements" and "non-functional requirements" come out of the BABOK and other standards and are not considered to be agile or related to user stories.”
Which led to another question along those same lines:
“If user stories are only functional, then how do we express non-functional requirements in agile?”
“Just the same way you would express non-functional requirements anywhere. Declarative statements, my boy, on the backlog. Just declarative statements. Remember, the backlog consists of backlog items, not only user stories.”
He looked at me with his trademark twinkle and replied:
“Besides how would you write a non-functional user story in the ‘ASA’ format? For example, a user story for a non-functional requirement in this format might read: “As a system I want to be able to handle up to 1000 users at a time without losing productivity so I can respond to all customer inquiries”? When systems and computers start giving us user stories, I hope I am not around to see it. Of course, with AI they say we are not far from that happening.”
His response reminded me of another question I had on my list, or should I say backlog. Absent mindedly I pointed to the question as though doctor BA could see the question on the paper in my hand, and began, “what.do we do about...”
Doctor BA held up his index finger to stop me. This was his sign that today's session was over and that I'd have to save the questions for our next meeting whenever that would be.
“Come back when I am ready,” said Dr. BA in his usual cryptic fashion as he mounted is old big tired bicycle, leaving me to wonder how I should know when he was ready. He shouted as he started pedaling: “I’ll be here. And remember: ask more questions.”
I watched as Dr. BA rode off on his bicycle like Mr. Chips without the robes, waving backwards at me as he disappeared into the mist.
!!! Do you have questions for Doctor BA? Add them in the comments section below or send an email to [email protected].
Previous Topics Tackled by Doctor BA:
Author: Steve Blais, PMP, PMI-PBA
Steve Blais, PMP, PMI-PBA, is an author, consultant, teacher and coach who has nearly 50 years’ experience in Information Technologies working as a programmer, project manager, business analyst, system analyst, general manager, and tester. He has also been in an executive position for several start-up companies. He develops business analysis and agile processes and trains business analysts, project managers, and executive for organizations around the world. He is the author of Business Analysis: Best Practices for Success (John Wiley, 2011) and co-author of Business Analysis for Practitioners: a Practice Guide (PMI, 2014) and a contributor to the Business Analyst Body of Knowledge, V3 (IIBA, 2015).