London Transport passengers are exhorted to “Mind the Gap” between the platform and the train. The gap’s dangerous.
Likewise, I exhort business analysts to “Mind the Gap” between the Stated Requirements and the Implied Requirements. If you don’t, you’ve doomed your team to scope creep (more like scope avalanche) and probably a lot of budget and schedule pressure, and it won’t be the sponsor’s fault.
Minding the Gap—getting the implied requirements close enough—is the difference between a requirements order-taker and a Business Analyst.
So, how do you come up with requirements that no one’s stating?
I got the idea from Doug Rosenberg’s & Kendall Scott’s “Robustness Analysis” and Ellen Gottesdiener’s “Multi-Modeling.” I invented the Requirements Merry-Go-Round© as a way to explain it to others. I’ve since found it useful for the other things I’ve been writing about.
The original Merry-Go-Round© had only two horses—Function and Data.
You start with Function—say Use Cases or User Stories. Imagine some (very simplified) software to help pilots with flight planning and navigation. Functional requirement elicitation turns up:
- As a Pilot, I can select my departure, arrival, and alternate airports when preparing my flight plan.
- As a Pilot, I can enter the departure runway when I’m given my departure clearance.
- As a Pilot, I can enter the arrival approach to the arrival airport, and the assigned runway for landing at the arrival airport, when I’m assigned them by the air traffic controller.
- As a Pilot, I can select Voice Mode and the software will read me the waypoints, altitudes, and speeds for approach and landing.
Now, you head off to your lonely analyst’s garret (if you’re just learning) or let your Subject-Matter Experts (SMEs) take a break (if you’re a rock star) and head around to Data.
Everyone who makes software learns to look at the functional requirements for nouns: Airport, Flight Plan, Departure Runway, Arrival Approach, and Arrival Runway (I left out a few to keep it simpler). Then, sketch a logical data model. Then, re-convene your SMEs for some more elicitation.
The crafty BA will have noticed the sloppy use of sometimes “enter,” sometimes “select,” and found out that there are lists of Airports, and each Airport has a list of Runways, and each Runway has multiple Approaches.
Then, for each entity on the data model, ask three simple questions:
- Where do these data come from?
- What are all the possible uses for these data, and by whom?
- When and how are these data disposed of, and by whom?
You’re checking for CRUD—Create, Read, Update, and Delete. Data have to come from somewhere, and be read by someone.
The Pilot enters the Flight Plan. That’s one of the stated requirements. And s/he selects Airports, Runways, and Approaches. This we know.
But where do the lists of Airports, Runways, and Approaches come from?
“Oh, I guess we’ll need screens to enter and edit them.” Inspired by Ruby on Rails, modern application frameworks in many programming languages, and modern programmer tools like Microsoft’s Visual Studio now have “scaffolding;” when you create a data entity, it just creates plain-vanilla versions of these screens for you.
“We get them in a file from the government.” I’ll leave it to you to imagine what you would need to find out next!
“That’s a good question. I was hoping you could tell me. I’m just the marketing guy—I’ve been going around to air shows, talking to pilots about what they would like our software to do.” Someone, maybe you, now has a research project that could invalidate the feasibility of the whole project. Disaster averted.
To summarize, here’s how to Mind The Gap and find the requirements that no one’s mentioned:
- Elicit the functional requirements—the ones that are driving the project
- Infer a logical data model from the nouns in the functional requirements
- Infer the implied functional requirements from the entities in the logical data model using the CRUD check (Create, Read, Update, Delete
You’re not done, though. Your implied functional requirements are just a first draft for another round of elicitation. Involve additional subject-matter experts (SMEs) and expect a flow of additional information. If the implied requirements touch another part of the organization, you may have a new senior stakeholder. Get the sponsor’s help in developing that relationship and working out a potential change in the business requirements as well.
You still might not get a bonus though. Disaster averted is disaster disbelieved.
“You can get on anywhere you like, but you have to go around at least twice.”
So far I’ve been emphasizing where to get on the Requirements Merry-Go-Round©. Start with Function if it’s up to you, but if the Subject-Matter Experts (SMEs) you’re working with want to get on at Data or User Interface, let them.
(I’ll come back to Business Rules in a future post because I need to find some misplaced material from the last WI BADD® first.)
But the first trip around is just the beginning. Like any other kind of research—scientific, historical, journalistic—requirements work has two main activities, which the BABOK® calls Elicitation and Analysis. Elicitation is about sources. You’ve read about how to help your subject-matter experts (SMEs) talk about Function, Data, and User Interface, and how to use one to get them talking about the others. That’s Elicitation.
Analysis happens when you go back to your lonely garret and try to make sense of it all. It’s the second and third trip around the Merry-Go-Round. On the second trip, I “freeze-dry” everything, by transcribing and annotating my source material. This sounds fancy but it isn’t. Read more of this article »
As a refresher, here’s the Requirements Merry-Go-Round©.
You can get on anywhere you like, but you have to go around at least twice. (I’ve double-ended the arrows since last week, because writing these has caused me to see that I change directions on the Merry-Go-Round a lot. No metaphor is perfect).
Most of the time, your sponsor or subject-matter expert (SME) will board at Function, because “being able to do things” is what the software is for. But sometimes, especially when enhancing or replacing an existing system, people will instead focus on all of the interesting things that are stored in the system—things I’ll loosely call “Data.”
I say “loosely” because the word “Data” can cause people to think too narrowly. It could be a document, a scan of a document, or an audio file of someone reading the document—you get the idea. So I usually use a word like Information, or even “What the system helps people work with.”
Modeling to talk about and describe Data
As with Function and its Use Cases and User Stories, the software profession has developed several ways to talk about Data. There are two main ones, Entity-Relationship (E-R) Diagrams and Class Diagrams (from UML, the Unified Modeling Language). Because these are also used by developers to talk about relational database design and object-oriented software design respectively, they have some very precise terminology and notation. Don’t go there when working with Sponsors or even SMEs (unless they’re pretty technical), and even then, try to stay out of the weeds.
One of my BA heroes, Ellen Gottesdiener, says, “You model requirements to facilitate communication.” Communication is like a freeway. When you overload it, it doesn’t just keep running at maximum capacity. It grinds to a complete halt.
The main things to model are
- Clumps of tightly related information, and
- The relationships between the clumps.
Precise definitions aren’t necessary, and can even get in the way at first.
Along with nearly everyone else, I use a boxes and lines. You can write attributes inside the box, label the relationships, and put some kind of markers on the relationship next to the boxes to indicate required, optional, and quantity.
UMLers like their numbers and asterisks and ERers like their crowsfeet. But what do Sponsors and SMEs like? Whatever you use, check that they understand. The best sign is when the SME corrects you. “There always has to be a Parent. Shouldn’t that be a one, not a zero?” That means you’re still communicating. You can tighten the lug nuts on the wheels of the truck later. The goal now is not to miss the fact that it’s pulling a trailer.
Eliciting Data from Function
How you talk about Data depends on where you got on the Merry-Go-Round.
If you started with Function, every BA knows to look at the nouns in the Function descriptions. In user-story style,
“A student completes an application to the program online. Students must provide information about at least one parent, because school policy requires a signed waiver from a parent or guardian, and the program needs a contact person on file in case of emergency.”
This follows the general,
“As a <role>, I can <do action> because <reason>” form of a user story, but in the way a subject matter expert might write it.
The initial data model might look like this:
The questions you ask are key. I might ask:
BA: Are there any other reasons why we need this parent/guardian information?
SME: “They also need someone to contact if the fees haven’t been paid.”
Huh. I just uncovered another User Story called “Someone Pays Student’s Fees.” If it’s not already on the list, I add it. It’s undoubtedly dragging more Data behind it. This is Merry-Go-Round thinking in action.
BA: Do the waiver person and the emergency-contact-person and the fee-paying person need to be the same person?
SME: “No, but they usually are.”
I would keep asking, next about adults who have more than one student in the program, but for this post, let’s move on.
Eliciting Data as the starting point
If you’re starting with Data because the first SME you talk to helped build the old system, they might even have a data model to show you. “Each Student has a one-to-many relationship with Parent.” Start a new model, though, like the one above.
Again, the questions are key. You use the model as a subject of conversation, and ideally you both add to it.
BA: Are there problems with this?
SME: “Yes, even though the table’s called Parent, they’re not always Parents. Sometimes they’re step-parents, or sometimes they’re legal guardians.”
BA: Does that matter?
SME: “Yes, school policy requires that there be a legal relationship between students and adults, for privacy and legal reasons.”
Here’s where more Merry-Go-Round thinking comes into play. If you’re thinking about requirements sequentially,
you might not pick up on that word “policy” as a Rule to talk about and understand, now. “That comes later,” or worse yet, that might be someone else’s interview. But ride around the Merry-Go-Round in your head and ask about that policy!
BA: Please tell me more about these privacy and legal reasons.
SME: “Well, I think it’s about the waiver form. Only a parent or legal guardian can sign one. You’ll have to talk to the Legal Department.”
BA: Who in Legal would be good to talk to about this?
SME: “Well, when we were sued that one time, Sally was over here wanting to know what we had on file and when it was entered.”
If Sally wasn’t on your list of people to talk to in Legal (if the plan even called for that), she’s on it now!
Often I’ll draw the Merry-Go-Round to show how I’m thinking. It often surfaces additional information.
SME: “Oh, now that I see that, another problem with the present system has to do with the fees. We record who pays the fees in a Payor table, and then things get out of whack because someone changes the Payor address and not the Parent/Guardian one, and then Development goes to do a mailing and they want an address list…”
Maybe I’m out of time or this SME doesn’t know anything more, but like someone clearing a mine field, I put a marker on the ones I suspect but didn’t confirm and remove or detonate. I’ve just heard about Fees and Payors and a stakeholder called Development and a mailing list.
More Merry-Go-Round thinking
Ellen Gottesdiener calls this type of merry-go-round thinking “Multi-Modeling.” You use one model to help with elicitation for the others.
Just like the nouns in Use Cases or User Stories often surface Data, the “because” clause often surfaces a policy or a rule. Don’t wait. Start that model now, visually, so you can get the SME thinking about it, too. (They can’t see what you’re writing in your notebook).
Likewise, when talking Data, ask your SME, “What are these data used for?” and “Where do they come from?” and “What problems arise because these data are stored like this?” It seems that most people like to talk about The Great Mailing-List Debacle of 2007. That often leads you to Rules and Functions—not all of them—but that doesn’t matter, because you’re going to go around the Merry-Go-Round at least twice, remember?
Syed Raman asked the IIBA LinkedIn group,
“Which way should i cover? Vertically ? Or horizontally? I have to meet my deadline..!!!” — most of the BAs face this part …Need some expert’s opinion.
If you can’t negotiate an extension, you have to perform triage. “What will cause the people downstream the most problems if left undone?” My starting answers, not knowing anything about the context, are:
- Requirements with a high architectural impact, and
- Requirements that are essential, but implied
If I don’t provide adequate guidance about #1, they are more likely to make a bad architectural decision, and those can be time-consuming and costly to fix later.
#2 might need some clarification. Suppose the stated requirements call for the system to provide information about X. But there are no stated requirements for putting information about X into the system. But without information about X, the primary requirements can’t be met. I should be asking, “Where does my system get information about X?“ That might uncover a whole interface to another system, or a set of input screens, and a team that will use them, and a whole new stakeholder! A gap this big could totally blow a schedule that’s probably already too “aggressive.”
That’s what I do. And when I get some time, I go upstream and find out where the schedule came from that didn’t allow me the time to do my job in the first place. That’s how I got involved with estimation and negotiation, a vital BA responsibility, IMO.
“Is it Project Manager, Architect, Tech Lead?”
This question was posed on Experts-Exchange.com, a resource I frequently use myself, and where I sometimes answer questions. Here’s a link to the dialogue, but if you don’t have a subscription, you won’t be able to see my answer.
For those of you without an EE subscription, here’s my answer, judged “Best Answer” by the questioner.
(I hate self-promotion, but I also have this food addiction that I just can’t seem to shake…) Read more of this article »
Those who wonder how to mesh Agile with a portfolio management or gating process will find some help in Agile Idea Qualification and Project Initiation, an engaging, 50-minute webinar by Sally Elatta.
Sally highlights the similarities between Agile and Lean. I wholeheartedly agree with her that the jelled, multi-functional team (BA, DBA, UI/UX, programmer, QA), not the individual “resource,” is the real unit of value creation in the software-intensive business. Rather than assembling teams around projects, flow work to teams.
In the early days, Agile started with, “in the beginning, there was the Project.” Sally backs up a couple of steps, to the Idea Qualification stage, which proceeds even Project Initiation. Tom Koulopolous teaches a lot of the same concepts. There are many more ideas than there is capacity to implement them, and that’s a good thing. Ideas are the gist of the innovation mill. There must be a central clearing house for idea evaluation, and it must be transparent and respectable. Though the norm, WSTL is just another form of the curse of local optimization.
Idea Qualification can, and must, be quick, both low effort and short cycle time. Sally recommends qualifying ideas by asking:
- What is its basic value proposition (make money, save money, improve customer satisfaction, improve competitiveness, stay in compliance, or KTLO—Keep The Lights On)? How can its success in delivering that value be evaluated? Qualitatively is better.
- Is it aligned with strategic direction? [Or, Iwould add, “Is it such a breakthrough idea that it represents a change in strategic direction?” This should be uncommon.]
- Does it have an empowered, engaged, knowledgable sponsor who is willing to see it through to Done and then take responsibility for the value created, 3-6 months after Done?
- Is it Feasible? (Do we have the time, money, know-how, and access to the necessary information and technology)?
Sally wisely recommends the use of a Kanban wall (visual representation of tasks and queues, with a limit on WIP—Work In Process—for every step) to manage Idea Qualification. Her explanation of a Kanban wall starting at about 28:45 in the webinar is very helpful. In addition to being Qualified, Ideas that are forwarded on to the next step, Project Initiation, must be prioritized. The Lean/Agile principle of minimal cycle time/WIP processes executed by standing teams off of a prioritized backlog, is used everywhere.
During Initiation, a portion of the implementation team, and the prospective sponsor, revisit the vision, measurable value, and feasibility (cost, skills, and technology) from Qualification, and add high-level requirements and costs, alternative solutions, a roadmap, and a bit more detail about how and when we will measure value. Projects that are approved to move on must also be prioritized. As Sally cleverly illustrates with the “Name Game,” starting at about 8:30 in the webinar, starting more projects than you have capacity just leads to multitasking which slows everything down.
Sally’s webinar provides a lot of help for business-side sponsors of software projects, which delights me because I think this is the hardest role and also the one with the greatest ability to affect significant change for the better. Starting at about 46:15 in the webinar, she provides a six-step process for evaluating value.
- Confirm (it should already have been identified) the value driver (revenue, cost, etc.)
- Identify the measure
- Gather as-is data (using the Lean principle of Go See)
- Define target measures—To Be—a valuable insight is to make this multiple thresholds, with a stretch goal and a target as well as a failure threshold; she also introduces probabilities or percentages, which is something I harp on when it comes to cost estimation
- Plan for and commit to measurement of actual outcomes
The higher the overall trust level in your organization, the better this will work. But even in a low-trust organization, there will be benefits, if you have the courage. One of the first gifts of Agile is transparency. Following this process of idea intake, qualification, initiation, and closing the loop with post-project measures, will reveal sources and sinks of trust.
I finally got around to conducting a half day of training for some local colleagues who bear the title “Business Analyst,” and whose organizations (and in some cases careers) had been shaken up by the arrival of the Agile Methods (most commonly Scrum) in the Early Majority. There were only four of us all together, so it was delightfully conversational.
Here’s what the whiteboard looked like when we were done. (Click for a full-size view).
Whiteboard after a 3-h presentation about Agile methods by Robert Merrill and Q&A with three Business Analysts
We started out by describing our own encounters with various Agile practices and knowledge of Agile methods in general.
I explained my concept of the Load-Bearing Walls, and shared my opinion that the ignorance, or politically-forced disregard, of these is going to lead to the failure of many Agile initiatives in Early-Majority adopters.
This led to a discussion of the concept of technical debt, and how it presents itself to the non-technical parts of the organization. Automated testing is the key to technical debt management on an Agile project, and can be a point of resistance. On the business side, I’ve sometimes successfully countered the assertion that it’s “extra work” by likening it to double-entry bookkeeping. Read more of this article »
This is the third of three parts on how to sabotage Agile adoption in your company, especially for Business Analysts.
If you want Agile to succeed, don’t do this stuff.
If you want Agile to fail because you’re benefitting from the status quo, good luck with that, too. Just make sure you have each item covered, especially the last one.
- Find like-minded saboteurs at other companies, so you can say, “They tried Agile at BigCo, and it was a disaster!”
- When assigned to an Agile project as Business Analyst (BA) or Product Owner, insist that all communication from business people to developers go through you, “To keep a handle on scope and keep things consistent.”
- As BA, insist that developers ask you all business questions first, because, “You know the business better than they do, and they’re all really busy anyway.”
- As BA, if instructed to coach people on User Stories or Test Cases, call in sick. Or just do it badly (but don’t be too obvious about it). On break, tell the most frustrated-looking person, “The only reason we’re doing this Agile stuff is that the CEO read about it in an in-flight magazine.”
- Hope that your firm’s competitors have people like you in them. When the ship you’re on sinks, proving that the leak wasn’t in your end won’t keep you from getting wet.
In case you missed them, here’s
How to Sabotage Agile, Part I and How to Sabotage Agile, Part II.
I got the idea for How to Sabotage Agile from a weather safety talk I once heard called “How to Get Hit By Lightning.” It’s more memorable and fun to read about what not to do.
- Tell the sysadmins, tech support folks, and in-house counsel that Agile means developers will be pushing code to production anytime they feel like it.
- Quote (or make up) inflammatory statements from famous Agilistas. “Sure, BAs, PMs, and QA people have a role on Agile teams–somebody has to make the coffee!”
- Tell the most introverted, opinionated developer in your shop that Agile will mean they will have to go out and gather all of the requirements themselves, with no help.
- Tell the most technophobic, opinionated business person in your firm that Agile will mean they will now have to talk to programmers, daily.
You’re in the middle. Don’t leave this to chance, do them all! See also How to Sabotage Agile, Part I and How to Sabotage Agile, Part III!