Running an FBA: A Practical Guide for School Teams

A functional behavior assessment is the work a school team does to figure out why a behavior keeps happening, so the plan that follows actually addresses the cause. The point is not to write a longer description of the behavior. The point is to identify its function: what the student gets or gets out of by doing it. This guide walks through the full process a school team can run, from the moment an FBA is triggered to the handoff into a behavior intervention plan.

When an FBA is triggered, and needing one versus wanting one

There are situations where an FBA is expected, and situations where a team simply wants more clarity. Both are valid, but they call for different effort.

You likely need a formal FBA when a behavior is interfering with the student's learning or the learning of others and lower-effort supports have not worked, when a behavior is dangerous, or when a disciplinary or placement decision turns on understanding the behavior. Schools remain responsible for their own legal and procedural obligations here, so check your local rules for when an FBA is required and who must sign off.

You may only want an FBA-style look when a behavior is mild, recent, or already responding to a classroom change you made last week. In that case a few days of informal ABC notes may answer the question without a full assessment. Knowing which situation you are in keeps the team from either skipping a required process or running a three-week assessment on something a seating change would fix.

It helps to place the FBA inside the larger support picture. In an MTSS frame, most behavior is handled by good universal practices and small classroom adjustments at the lower tiers. The FBA is what you reach for when those have been tried and the behavior is still interfering, or when the behavior is serious enough that you cannot afford to keep guessing. If nothing has been tried yet, an FBA can feel premature, and a short, documented attempt at a simpler support first will both help the student and strengthen the case that a full assessment is warranted. The exception is a behavior that is dangerous, where waiting through a tier of low-effort supports is not appropriate and the team should move directly to a careful assessment.

Who does what on the team

An FBA is a team task, and the work goes faster when roles are named on day one rather than assumed.

One person should own the write-up. When everyone contributes data but no one is responsible for the summary, the FBA stalls in a shared folder. Decide who interviews, who observes, and who writes before any data is collected.

Gather indirect data first

Before you spend a single observation minute, collect what already exists. Indirect data is faster to gather and it tells you where to point your direct observation.

Start with a record review. Read past incident reports, attendance, health notes, prior plans, and any earlier behavior data. Look for patterns the team may already have without realizing it: a time of day that keeps showing up, a subject that recurs, a change that lined up with the behavior starting. Attendance and health notes are easy to skip and often the most revealing, because a behavior that worsens on days following an absence or a poor night of sleep is pointing you toward setting events you would otherwise miss. Pay attention to when prior plans worked and when they stopped working, since a support that helped for a month and then faded can tell you as much about the function as the behavior itself.

Then interview the people who know the student. Teacher and parent interviews are where the early hypothesis usually forms. Ask questions that get at antecedents and consequences, not just descriptions.

Questions worth asking a teacher or parent:

1. When is the behavior most and least likely? Time of day, subject, setting, who is present.
2. What is usually happening right before it starts?
3. What do you or others typically do once it happens?
4. What does the student seem to get, or get out of, when it works?
5. Are there days it almost never happens, and what is different about those days?

That excerpt already suggests two threads worth testing with direct data: escape from an independent task and adult attention. Indirect data rarely settles the question by itself, but it tells the observer exactly where to look.

Define the target behavior before you observe

The single most common reason multi-observer FBA data does not line up is that observers were watching different behaviors. One person counts every time the student speaks out of turn, another only counts the loud ones, a third includes muttering. The data then contradicts itself for no real reason.

Fix this by writing one observable behavior definition the whole team uses, before observation starts. A good definition passes a simple test: two people watching the same moment would agree on whether it counted. "Disruptive" fails the test because it is a judgment. "Out of seat and more than ten feet from the assigned area" passes it, because there is nothing to interpret.

Pick one or two target behaviors, not five. An FBA that tries to assess everything a student does at once produces thin data on each. Choose the behavior that is most interfering or most dangerous, define it in plain observable terms, and write it at the top of every log so it travels with the data.

Plan the direct observation

Direct observation is where you watch the behavior happen and record antecedent, behavior, and consequence in real conditions. Plan it deliberately so your limited minutes land on the behavior.

Decide four things before you start:

1. Where. The settings the interviews flagged, and at least one contrasting setting where the behavior is rare.
2. When. The times of day the behavior is most likely, so sessions are not wasted on calm stretches.
3. How long. A fixed window, like 20 to 30 minutes per session, so sessions are comparable to each other.
4. How you will log. One shared ABC format and one observable behavior definition every observer uses.

A common mistake is observing all day and hoping the behavior shows up. Instead, sample the windows where the behavior is most likely and watch a defined block each time. Several short, comparable sessions across different settings beat one long, unfocused one.

Set up your ABC log so the columns are filled the same way every time. Antecedent is what happened right before. Behavior is the observable action, defined the same way across observers. Consequence is what happened right after, including the adult response. If you want a ready format, an ABC observation log keeps these fields consistent so multi-observer data lines up instead of turning into several different stories.

Build the function hypothesis from converging evidence

Once data is coming in, you are looking for a pattern that repeats across sessions, settings, and people. There are four functions a behavior can serve, and each tends to leave a recognizable signature in the ABC data.

Convergence is the word that matters. One observer noticing the behavior after a hard task is a lead. The same antecedent showing up across three observers, two settings, and the parent interview is a hypothesis. If the evidence pulls in different directions, you are not done collecting, or you may be looking at two functions in two contexts.

Watch the consequence column closely, because the consequence is what is maintaining the behavior. If the worksheet always waits while an adult comes over, the behavior is being fed whether or not anyone intends it. The FBA is not blaming the adult response. It is naming it so the plan can change it.

Setting events deserve their own attention here. A setting event is a background condition that makes the behavior more or less likely without being the immediate trigger: a missed breakfast, a rough bus ride, a substitute, poor sleep, a medication change. The same writing task that produces nothing on Tuesday produces refusal on Thursday because Thursday started badly. If your log notes setting events, you can explain why the behavior seems inconsistent, and you avoid building a hypothesis on a single unusual week. When the data looks contradictory, a setting event is often the missing variable.

It also helps to check the behavior against more than one function before you commit. Ask, for each candidate function, what the data would look like if that were the cause, and then see whether your rows match. Escape predicts that removing the task ends the behavior. Attention predicts that the behavior keeps going until someone responds. Tangible predicts it stops when access returns. Sensory predicts it continues regardless of any social response. Running your data past all four, rather than confirming the first one that seems to fit, is what keeps the hypothesis honest.

Write the FBA summary statement

The summary statement is the product of the whole assessment. It pulls the converging evidence into one statement the team can act on. A workable format names the setting events and antecedents, the behavior, and the function the data supports.

Notice that the summary leads with the data pattern and only then states the function. A summary statement that asserts a function without the supporting counts is a guess wearing a uniform. The counts are what let the next team trust it.

Hand off from FBA to BIP

The FBA ends where the behavior intervention plan begins. A good handoff means the BIP team does not have to reinterpret the behavior. They take the summary statement and build directly on it.

The function in the summary statement points to the replacement behavior. If the function is escape from writing, the plan teaches a better way to get a break or to ask for help, and it changes the antecedent so the task is more doable. If the function is attention, the plan front-loads attention rather than waiting for the behavior to earn it. A plan that does not match the function will not work, no matter how detailed it is.

Bring the summary statement, the ABC data behind it, and the replacement-behavior idea into the BIP conversation as one package. A BIP planning canvas can structure that handoff so the function, the antecedent changes, the replacement behavior, and the progress measure all trace back to the same FBA. Where a school keeps its ABC incidents next to the daily chart, as in Evident, the summary and the underlying data stay together instead of living in separate documents that have to be reassembled before the meeting.

The replacement behavior is the hinge of the whole handoff, so name it carefully. It has to serve the same function as the problem behavior, only through an acceptable means, and it has to be at least as easy and as fast for the student. If escaping a writing task currently takes one episode of refusal, then asking for a short break has to work just as reliably, or the student will go back to what worked. A replacement behavior that is slower or less certain than the original will lose, and the plan will look like a failure when it is really a mismatch.

Common pitfalls that weaken an FBA

A few predictable mistakes account for most FBAs that go nowhere. Knowing them in advance is the cheapest way to avoid them.

The first is describing instead of explaining. A document that catalogs everything the student did but never names a function is a behavior log, not an FBA. If your summary could be swapped for any student with the same behavior, you have described, not assessed.

The second is collecting data only where it is convenient. If every session is in the same room with the same adult, you cannot tell function from context. Get at least one contrasting setting, even a short one.

The third is treating the hypothesis as final. The FBA is a best current explanation, and the plan built on it is a test of that explanation. When the plan does not work, the right first question is whether the function was right, not whether to add a consequence.

The fourth is leaving the family out until the meeting. Parents often hold the setting-event information that explains your most confusing days, and they have usually seen the behavior in contexts the school never will. Bring them in during data collection, not after the conclusions are written.

A short note on honesty in the process

An FBA is a hypothesis backed by data, not a verdict. You may be wrong, and the right response when a plan built on the FBA does not work is to revisit the function, not to add consequences. Keep your behavior definitions observable, keep your counts honest, and keep the family in the loop. The assessment is only as good as the data underneath it, and the data is only as good as the care taken while collecting it.