The most common question a behavior team asks midway through an FBA is whether they have enough ABC data yet. People want a number. The honest answer is that there is no magic number, because the goal is not a row count. The goal is a pattern that holds up across settings, observers, and days. This article gives you practical floors so you are not starting from nothing, the signals that tell you to stop, the signals that tell you to keep going, and a worked example of the moment a pattern becomes clear.
Convergence, not counts
Data collection ends when the evidence converges, meaning several independent looks at the behavior point to the same function. Ten rows that all say the same thing in one setting are weaker than six rows that agree across two settings and two observers. A high count from a single context can fool you, because it might only be telling you about that one context.
So the question is not how many rows you have. It is whether the antecedent and consequence pattern repeats when the person, the place, or the day changes. When it does, and another session would not move your read, you are done. Counting rows is a proxy that sometimes works and often misleads.
It is worth saying why teams reach for a number anyway. A count feels safe and defensible, and it gives a clear stopping point in a process that otherwise feels open-ended. The trouble is that a count can be satisfied by repetition that proves nothing. Twenty rows from one teacher in one class can be perfectly consistent and still leave you blind to whether the behavior happens for the same reason in the hallway, at lunch, or with a different adult. Convergence asks a harder and more useful question than "how many," which is "across how many different conditions does this still hold."
Practical floors to start from
Convergence is the real test, but teams still need somewhere to begin so they are not under-collecting on a behavior that needs a careful look. Match the window to how often the behavior happens.
| Behavior frequency | Suggested observation window | Sessions to aim for | Spread across |
|---|---|---|---|
| Many times per hour | 15 to 20 minutes during the likely time of day | 3 to 4 | 2 settings, a few days |
| A few times per day | 30 to 45 minutes covering a likely block | 4 to 6 | Different times and people |
| About once a day | The full period where it usually occurs | 5 to 8 | 2 to 3 weeks |
| A few times per week | The recurring activity or trigger window | 6 to 8 | 2 to 4 weeks |
These are floors, not finish lines. A high-frequency behavior can converge in a few well-placed sessions, while a rare but serious behavior may take weeks simply to gather enough instances to see anything. Use the table to plan, then let the pattern tell you when to stop.
Two practical notes on the windows. Spread your sessions across different times of day and different people, not all in the same block with the same adult, because spreading them is what tests whether the function holds beyond one context. And resist the urge to stretch every window long. A 20-minute window that lands squarely on the likely trigger gives you cleaner, more comparable data than a 90-minute window that mostly captures calm. The aim is several short, comparable looks under varied conditions, which is exactly the shape of data that lets you see convergence rather than just accumulate rows.
Three signals you have enough, and two to keep going
Reading the data as it comes in is what lets you make this call. Watch for these.
- The same antecedent keeps showing up. Across sessions, settings, and observers, the behavior follows the same trigger most of the time. Repetition across contexts is the strongest sign you have a real pattern.
- The consequence is consistent. The thing that follows the behavior, and likely maintains it, is the same across instances. A stable antecedent and a stable consequence together name the function.
- A new session would not change your read. When you can predict what the next row will look like and you keep being right, the data has settled. That predictability is your stop signal.
- The data is contradictory: keep collecting. If the antecedents or consequences pull in different directions and you cannot yet split them by context, you do not have a hypothesis. Collect more, especially in the settings where it is muddiest.
- The settings that matter are thin: keep collecting. If all your data comes from one class but the behavior is reported across the day, you are missing the contexts that would confirm or break your hypothesis. Go get those sessions before you stop.
What not-yet-enough looks like
The stop signals are easier to trust when you can recognize their opposite. Here is a log that is not ready to call, not because the behavior is mysterious, but because there are too few rows from too narrow a slice of the day.
A composite third grader we will call Theo. The behavior is calling out. Four rows, collected over two days, all during morning meeting:
| # | Antecedent | Behavior | Consequence |
|---|---|---|---|
| 1 | Teacher asked a group question | Called out the answer | Teacher responded to him |
| 2 | Transition to the carpet announced | Called out "I am not ready" | Teacher waited for him |
| 3 | Teacher asked a group question | Called out something off-topic | Redirected, peers laughed |
| 4 | Open work time announced | Called out a question | Teacher answered it |
Two rows look like attention (an adult or peers respond) and two look tied to transitions or tasks. With four rows from one setting at one time of day, you cannot yet tell whether Theo calls out to gain attention, to manage transitions, or both. This is not a competing-hypothesis case to write up. It is an under-collected one. The fix is more sessions across different times and activities, not a hypothesis.
A worked example of the pattern becoming clear
Numbers in a table are abstract until you watch a pattern emerge from real rows. Here is a log where the function was not obvious at row three and was hard to miss by row ten.
A composite sixth grader we will call Ruby. The behavior is leaving class without permission. The annotations in brackets are the team reading the data as it came in.
| # | Antecedent | Behavior | Consequence |
|---|---|---|---|
| 1 | Group discussion started | Left for the bathroom | Returned in 5 min |
| 2 | Independent essay assigned | Left for the nurse | Missed the essay [first lead: a demand?] |
| 3 | Quiz handed out | Left for the bathroom | Took quiz late, shortened |
| 4 | Read-aloud (low demand) | Stayed in seat | n/a [counter-case: no leaving when no task] |
| 5 | Independent worksheet | Left for the office | Worksheet not done |
| 6 | Partner activity | Stayed in seat | n/a [pattern holding: only solo written work] |
| 7 | Timed writing prompt | Left for the bathroom | Prompt skipped [escape signature clear] |
| 8 | Independent reading log | Left for the nurse | Log not completed |
| 9 | Group project | Stayed in seat | n/a |
| 10 | Independent test | Left for the bathroom | Test taken in resource room, untimed [pattern confirmed] |
By row seven the team could predict the next row, and rows eight through ten confirmed it. Leaving clustered on independent written tasks and never on group or low-demand activities, and each departure delayed or removed the task. The function is escape from independent written work. Notice that the in-seat rows were as informative as the leaving rows, because they showed the absence of the trigger produced the absence of the behavior. Stopping at row three would have left the team guessing.
This is the part teams often skip: the negative cases matter. It is tempting to log only the instances where the behavior happened, but the moments where the trigger was present and the behavior did not occur, and the moments where the behavior was absent because the trigger was absent, are what turn a hunch into a confirmed pattern. A log full of only the bad moments can make almost any function look plausible. A log that also captures the calm matched against the same conditions tells you whether your antecedent is really doing the work.
Reading the data as it arrives, rather than waiting until the end, is also what makes the stopping decision possible. If you wait until you have a stack of sessions and only then look, you cannot tell whether session four or session eight was the one that settled the question, and you may have collected three sessions you never needed or stopped two short. Glancing across your rows after each session is what lets the pattern, not the calendar, tell you when to stop.
Setting events can distort the picture
One more caution before you trust a pattern. The conditions around the data matter as much as the data.
The short version: enough is when the pattern holds across settings, observers, and ordinary days, and one more session would not change what you already see. Use the floors to plan, read the data as it arrives, and let convergence rather than a row count tell you when to put the log down.
Common questions
Is there a minimum number of ABC observations for an FBA?
There is no universal number. A practical floor for a behavior that happens several times a day is three to five sessions across different settings and people. The real test is whether the pattern repeats, not whether you reached a count.
How do I know when to stop collecting?
Stop when the same antecedent and consequence pattern shows up across settings and observers, the function is clear, and another session would not change the picture. Keep going if the data is contradictory or thin in the settings that matter.