You do not master DAX by memorizing a longer list of functions. You master DAX by predicting what a measure should return, testing it under different filter contexts, and explaining why the result changed.
This 30-day DAX practice plan is built around that loop. It assumes 30 to 45 focused minutes a day and a basic familiarity with Power BI. By the end, you should be able to write useful measures, diagnose common mistakes, and recognize when the problem is the model rather than the formula.
What “master DAX” should mean
DAX mastery is not knowing every function in the language. Even experienced developers look up function signatures. A more useful definition is that you can:
- translate a business question into a precise calculation;
- identify the grain at which the calculation should run;
- predict the active filter context;
- choose between a measure, calculated column, or calculated table;
- use
CALCULATEdeliberately instead of by trial and error; - test row values, subtotals, and grand totals separately;
- reduce a broken measure to a small reproducible example; and
- explain the tradeoff behind your final formula.
Microsoft’s introductory DAX guidance frames the language around syntax, functions, and context. That is a good starting point, but context deserves most of your practice time because it is where correct-looking formulas quietly produce the wrong answer.
The daily DAX practice loop
Use the same five-step loop every day:
- Predict: Write down the number or behavior you expect before running the measure.
- Write: Create the smallest measure that could answer the question.
- Vary: Test it by product, date, customer, and at the total.
- Explain: Describe the current filter context in plain language.
- Refactor: Improve the measure only after the first version is correct.
That loop turns every formula into a small experiment. It also prevents a common failure mode: changing several parts of a measure at once and no longer knowing which change mattered.
If you need a place to run those experiments without building a new report from scratch, use a DAX playground and keep a short log of the cases that surprised you.
Week 1: Build measures on a clean model
The first week is about learning to see the model before seeing the formula.
Day 1: Identify the grain
Open a simple star schema with a Sales fact table and Product, Customer, and Date dimensions. For each table, write one sentence describing what a row represents.
Then answer:
- What is the grain of
Sales? - Is one row an order, an order line, or a daily total?
- Which column uniquely identifies each dimension row?
- Which filters should flow into Sales?
If the grain is unclear, any average, ratio, or distinct count built on top of it will be fragile.
Day 2: Write three base measures
Start with measures that make as few assumptions as possible:
Total Sales =
SUM ( Sales[Sales Amount] )Order Count =
DISTINCTCOUNT ( Sales[Order Number] )Average Order Value =
DIVIDE ( [Total Sales], [Order Count] )Put all three in a matrix by Product Category. Before checking the grand total, calculate one category by hand.
Day 3: Measures versus calculated columns
Create one measure and one calculated column that appear to answer a similar question. Observe when each one is evaluated.
A calculated column is computed during data refresh and stored row by row. A measure is evaluated when a query asks for it, under the filter context of that query. Slicers do not dynamically recalculate a stored calculated column.
This distinction will matter later when functions such as SELECTEDVALUE seem to work in a measure but return blank in a calculated column.
Day 4: Read filter context from a visual
Build a matrix with:
- Product Category on rows;
- Year on columns;
- Total Sales as the value; and
- Region in a slicer.
Choose one cell and state every filter active for that cell. Then state the filters active for its row subtotal and the grand total.
Our guide to row context versus filter context goes deeper into this distinction.
Days 5–7: Rebuild, test, and review
Rebuild the three measures without looking at your previous code. Add tests for:
- no slicer selection;
- one slicer selection;
- multiple selections;
- a category with no sales; and
- the grand total.
On day 7, do not learn a new function. Review every result you could not predict.
Week 2: Learn what CALCULATE changes
CALCULATE is not difficult because of its spelling. It is difficult because it changes the filter context in which an expression is evaluated.
Day 8: Add one filter
Blue Sales =
CALCULATE (
[Total Sales],
Product[Color] = "Blue"
)Test it in a visual that already filters Product Color. Ask whether the new filter replaces or intersects with the existing filter.
Day 9: Remove one filter
Sales All Products =
CALCULATE (
[Total Sales],
REMOVEFILTERS ( Product )
)Then calculate a share:
Product Share =
DIVIDE ( [Total Sales], [Sales All Products] )Check whether Date and Customer filters still apply. They should. Removing Product filters is different from clearing every filter on the fact table.
Day 10: Preserve an existing filter
Use KEEPFILTERS in a case where a filter argument touches a column already filtered by the visual. Compare the result with the same measure without KEEPFILTERS.
The goal is not to memorize “always use KEEPFILTERS.” The goal is to notice whether a filter should replace an existing selection or intersect with it.
Days 11–14: Practice context transitions
Create a measure reference inside an iterator:
Average Customer Sales =
AVERAGEX (
VALUES ( Customer[CustomerKey] ),
[Total Sales]
)For one iteration, describe:
- the row currently being iterated;
- the filter context before the measure reference; and
- the filter context under which
[Total Sales]is evaluated.
This is context transition in practice. Build two more examples with Product and Month, then spend day 14 explaining them without code.
Week 3: Practice iterators, totals, and time
Week 3 is where many formulas become syntactically valid but semantically wrong.
Days 15–16: Choose the right grain for an iterator
Suppose the business wants the sum of a threshold calculation evaluated once per product:
Sales From Large Products =
SUMX (
VALUES ( Product[ProductKey] ),
IF ( [Total Sales] >= 10000, [Total Sales], 0 )
)Changing Product[ProductKey] to Product Category changes the question. Both formulas can run. Only one matches the requested grain.
Day 17: Debug a wrong total
Power BI normally reevaluates a measure at the grand-total filter context; it does not simply add the visible rows. Compare the direct total with an explicit iterator over the visible grain.
Use the workflow in 5 DAX debugging habits that find wrong totals faster: reproduce the issue in the smallest visual, expose context, and test one assumption at a time.
Days 18–20: Time intelligence with a proper Date table
Create:
Sales YTD =
CALCULATE (
[Total Sales],
DATESYTD ( 'Date'[Date] )
)Sales Previous Year =
CALCULATE (
[Total Sales],
SAMEPERIODLASTYEAR ( 'Date'[Date] )
)Test complete and incomplete years. Verify that the Date table is continuous, related correctly, and used in the visual.
Day 21: Mixed review
Complete five short problems without being told which function to use. Real work arrives as business questions, not function-name prompts.
The DAX practice exercise pack is designed for this type of review.
Week 4: Debug, validate, and explain
The final week replaces “it returns a number” with stronger evidence.
Day 22: Build a test matrix
For one important measure, create a table with these cases:
| Case | Expected behavior |
|---|---|
| No filter | Full-model result |
| One product | Product-specific result |
| Multiple products | Combined result |
| Empty period | Blank or zero by design |
| Row subtotal | Recalculated at subtotal context |
| Grand total | Business-defined total behavior |
Do not accept the measure until each case is intentional.
Day 23: Use diagnostic measures
Expose the values visible to the engine:
Visible Products =
CONCATENATEX (
VALUES ( Product[Category] ),
Product[Category],
", "
)Temporary measures like this are often more useful than immediately rewriting the production formula.
Day 24: Separate syntax from correctness
A parser can tell you that parentheses are unbalanced. It cannot tell you whether the business wanted a weighted average, whether Product filters should remain active, or whether the grand total should iterate customers.
Read what a DAX syntax checker catches—and misses and apply its validation ladder to one measure.
Days 25–27: Read and refactor
Take three working measures and improve their readability:
- use descriptive variable names;
- separate business steps with variables;
- remove repeated expressions;
- format consistently; and
- add a short comment only where the business rule is not obvious.
Do not refactor all measures into the same shape. Clarity depends on the problem.
Days 28–29: Solve without hints
Choose two unfamiliar DAX challenges. Give yourself a time limit, but keep the prediction-and-test loop. If you get stuck, reduce the problem before asking for a hint.
Day 30: Explain one measure to another person
Pick the measure you found hardest and explain:
- the business question;
- the model grain;
- the starting filter context;
- every filter changed by the formula;
- how the total is evaluated; and
- the tests that prove it.
If you can explain those six things clearly, you understand more than the final syntax.
What to do after the 30 days
Repeat the plan with harder scenarios rather than collecting more passive tutorials. Keep a small failure library with:
- the original wrong measure;
- the smallest case that exposed the problem;
- the filter-context explanation;
- the corrected measure; and
- the test that prevents the mistake from returning.
That library becomes your personal DAX reference. It is more valuable than a list of functions because it records how your reasoning changed.
The shortest route to mastering DAX is deliberate repetition: predict, write, vary, explain, and refactor. Start with one DAX practice challenge today, then come back tomorrow and solve it again from memory.
