The Constant Comparative Method: A Step-by-Step Guide

Short answer: The constant comparative method is a way of analysing qualitative data in which you compare every new piece of data with everything you have already coded, while you are still collecting data. You compare incident with incident, then incidents with the categories they suggest, then categories with each other, writing memos as ideas come up and choosing who to interview next based on what the comparisons show. Barney Glaser and Anselm Strauss set it out in four stages: comparing incidents applicable to each category, integrating categories and their properties, delimiting the theory, and writing the theory. It is the engine of grounded theory, but product and UX teams use it any time they want findings that are built up from the data instead of sorted into boxes decided in advance.

This guide explains where the method comes from, walks through each stage with a product research example, covers how to know when to stop, and shows how Koji supports constant comparison as interviews come in.

Where the method comes from

Glaser first described the method in a 1965 paper, "The constant comparative method of qualitative analysis", in the journal Social Problems. Two years later it became a central chapter of The Discovery of Grounded Theory (Glaser and Strauss, 1967), the book that launched grounded theory.

At the time, qualitative researchers tended to choose between two approaches. Some coded all their data first and then tested hypotheses against it. Others read their notes for ideas without systematic coding. Glaser proposed joining the two: code and analyse at the same time, and let each comparison shape the next. His defining rule is simple:

"While coding an incident for a category, compare it with the previous incidents in the same and different groups coded in the same category." (Barney Glaser, 1965)

He was also clear about what the method does not promise. It is meant to generate categories, properties and hypotheses, not to prove them, and it is "not designed (as methods of quantitative analysis are) to guarantee that two analysts working independently with the same data will achieve the same result." That matters if a stakeholder asks for an inter-rater score: constant comparison is judged by how well its categories fit and explain the data, not by coder agreement.

The four stages

The stages are not a strict sequence. Glaser and Strauss describe each one as continuing to run while the next begins, until the analysis ends.

Stage 1: Compare incidents applicable to each category

Code each incident (a passage in an interview, an observed event, a line in a document) into as many categories as it fits. Each time you code an incident, compare it with the incidents already in that category.

Example. You are interviewing customers who downgraded a project management tool. Participant 3 says they moved to a spreadsheet "because the team just stopped updating tasks". You code it under "team stopped using it". Then you compare it with participant 1, who said "the boards went stale after the launch". Are these the same thing? Both are about usage fading, but one is about people, the other about a moment in time. The comparison starts to reveal properties of the category: who stops first, and when.

When an idea strikes during this comparison, stop and write a memo. Memos are where categories get their definitions and where the theory starts.

Stage 2: Integrate categories and their properties

As the number of incidents grows, the comparison shifts from incident against incident to incident against the properties of the category. You stop asking "is this like that quote?" and start asking "what does this tell us about the category?"

Properties can take many forms: conditions, consequences, types, dimensions and processes. In the downgrade study, "team stopped using it" might gain properties such as trigger (a launch ends, a champion leaves), speed (gradual or sudden) and visibility (managers notice or don't). Categories start linking to each other: "champion left" turns out to be a condition for "team stopped using it".

Stage 3: Delimit the theory

The theory starts to firm up. Fewer changes are needed, categories merge, and you can explain more of the data with fewer concepts. Two things narrow the work:

• Reduction. You find underlying uniformities and drop properties that don't earn their place.
• Theoretical saturation of categories. New incidents stop adding new properties to a category, so you code them only when they add something.

This is also when you lean hardest on theoretical sampling: choosing the next participants to test or fill out specific categories. In the downgrade study, if "champion left" looks central, you deliberately recruit customers whose champion left but who did not downgrade.

Stage 4: Write the theory

By now you have coded data, a set of memos and a smaller set of well-defined categories. The memos supply the content of the write-up, and the categories become its main sections. Good writing at this stage stays traceable: every claim should lead back to the comparisons and incidents that produced it.

How to run constant comparison in practice

• Analyse after every interview, not after the last one. The method only works if analysis shapes what you ask and who you ask next. Block time after each session.
• Keep three levels of comparison going. Incident with incident, incident with category, category with category.
• Memo early and often. A memo can be two sentences. Date it and link it to the incidents that prompted it.
• Look for cases that don't fit. A participant who breaks the pattern is the most useful comparison you can make. See negative case analysis.
• Let the interview guide change. Add questions that probe emerging categories and drop ones that have stopped producing anything new.

Keep collecting while you compare

Because analysis and data collection run together, constant comparison changes how you plan fieldwork. Instead of booking 20 interviews up front and analysing at the end, plan in waves: a first wave to open up categories, then smaller waves chosen to fill gaps. Spread sessions out enough that you can code and memo between them.

Photo by UX Indonesia on Unsplash

How do you know when to stop?

The usual answer is theoretical saturation, when new data stops changing your categories. Several studies give a sense of the numbers involved, though none of them is a rule:

• In a study of 60 interviews, Guest, Bunce and Johnson (2006) found that 92% of the codes developed for one country's 30 transcripts had appeared within the first twelve interviews.
• Hennink, Kaiser and Marconi (2017) found code saturation at nine interviews, but needed 16 to 24 interviews to reach meaning saturation. In their words, code saturation may show when researchers have "heard it all", but meaning saturation is needed to "understand it all".
• A 2024 analysis of five studies in JMIR by Squire and colleagues found that near saturation came after 33% to 60% of planned interviews (15 to 23 interviews), but true saturation needed 91% to 100% (30 to 67). Studies that relied heavily on deductive coding, or used a more structured interview guide, reached saturation sooner.

The practical takeaway for constant comparison: topics appear early, but properties and relationships between categories take longer. Stop when new interviews stop changing your categories, not when they stop producing new topics. For more, see data saturation in qualitative research.

Constant comparison compared with other approaches

You don't have to adopt full grounded theory to use constant comparison. Many teams borrow the habit, analysing each interview against the last ones, inside a looser thematic analysis.

Common mistakes

• Batch analysis with a grounded theory label. If all coding happens after the last interview, it is not constant comparison.
• Comparing only similar cases. Differences sharpen categories. Seek them out.
• No memos. Without memos, the reasoning behind categories is lost and the write-up becomes a list of codes.
• Declaring saturation without evidence. Record when categories last changed so you can show why you stopped.
• Forcing early categories. Early categories are hypotheses. Let later comparisons split, merge or drop them.

How Koji helps

Constant comparison asks for something manual workflows make hard: analysing each interview soon after it happens, while recruitment continues. Scheduling, transcribing and coding by hand usually push analysis to the end. Survey tools collect fast but rarely give enough depth to compare incidents in a meaningful way. Koji is built so analysis keeps up with collection.

• Interviews run in parallel, around the clock. Koji's AI-moderated interviews run by text or voice, so participants take part when it suits them and you don't have to moderate each session.
• Each interview is coded as soon as it is done. Koji codes every answer question by question, and every label is backed by a verbatim quote from the participant. You can read the analysis of interview 4 before interview 5 starts.
• Cross-interview comparison in the report. The report groups related phrasings from different interviews into themes and shows how many interviews mention each one, with the supporting quotes one click away. That is stage 1 and stage 2 comparison laid out for you to question.
• A signal for when themes are still moving. When a study has only a few interviews, the report says that themes are still emerging and may change as more interviews arrive, so you don't mistake early patterns for settled ones.
• Reports that grow with the study. Refresh the report as new interviews come in. Earlier versions stay in the report history, which gives you a record of how your categories changed, useful evidence when you argue that you reached saturation.
• Guides you can adjust between waves. Duplicate a study to run the next wave with a revised guide, or add structured questions to test an emerging category. The JMIR finding above suggests a more structured guide can help you reach saturation sooner.

Koji does the coding and grouping. The comparison, memoing and theory building stay with you, and that is where the method's value lies.

Related Resources

• Grounded Theory in Qualitative Research
• Open, Axial, and Selective Coding
• Structured Questions Guide
• Data Saturation in Qualitative Research
• Negative Case Analysis
• In Vivo Coding

FAQ

What is the constant comparative method in simple terms? It is a way of analysing qualitative data where you compare each new piece of data with what you have already coded, while you are still collecting data. The comparisons build categories, and the categories build a theory.

Who developed the constant comparative method? Barney Glaser described it in 1965, and it became a core part of grounded theory in Glaser and Strauss's The Discovery of Grounded Theory (1967).

What are the four stages of the constant comparative method? Comparing incidents applicable to each category, integrating categories and their properties, delimiting the theory, and writing the theory. The stages overlap rather than running strictly in order.

Can I use the constant comparative method without doing grounded theory? Yes. Many researchers use constant comparison inside thematic or other qualitative analysis to make sure each new interview is compared with earlier ones, without aiming to produce a formal theory.

How is constant comparison different from thematic analysis? Thematic analysis is often done after data collection and can use a codebook. Constant comparison happens during collection, and its comparisons decide who you sample and what you ask next.

Sources

• Glaser, B. G. (1965). The constant comparative method of qualitative analysis. Social Problems, 12(4), 436–445.
• Glaser, B. G., & Strauss, A. L. (1967). The Discovery of Grounded Theory: Strategies for Qualitative Research. Aldine.
• Guest, G., Bunce, A., & Johnson, L. (2006). How many interviews are enough? An experiment with data saturation and variability. Field Methods, 18(1), 59–82.
• Hennink, M. M., Kaiser, B. N., & Marconi, V. C. (2017). Code saturation versus meaning saturation: How many interviews are enough? Qualitative Health Research, 27(4), 591–608.
• Squire, C. M., Giombi, K. C., Rupert, D. J., Amoozegar, J., & Williams, P. (2024). Determining an appropriate sample size for qualitative interviews to achieve true and near code saturation: Secondary analysis of data. Journal of Medical Internet Research, 26, e52998.