Bayesian Data Analysis course - Project work

Published

October 27, 2026

Project work details

Project work involves choosing a data set and performing a whole analysis according to all parts of the Bayesian workflow studied in the course.

  • The project work is meant to be done in period II.
  • At the beginning of period II
    • Form a group of 2–3 students. Working in a group is strongly encouraged, both because discussing the project with others supports learning and because it makes the project presentations more manageable. Single-student groups are allowed only in exceptional situations.
    • Select a topic. You may ask in the course chat channel #project for an opinion on whether it’s a good topic and a good dataset. You can change the topic later.
    • Start planning.
  • The main work for the project and the presentation will be done in the second half of period II after all the workflow parts have been discussed in the course.
  • The in-person presentations will be made during the evaluation week after period II.
  • Use of AI is allowed on the course, but the most of the work needs to by the students, and you need to report whether you used AI and in which way you used them (See points 5 and 6 in Aalto guidelines for use of AI in teaching). We have tested some AI on the course topics and assignments and the output can be copy of existing text without attribution (ie. plagiarism), vague or have mistakes, so you need to be careful when using such outputs.
  • All suspected plagiarism will be reported and investigated. See more about the Aalto University Code of Academic Integrity and Handling Violations Thereof.

Project schedule

  • Form a group and pick a topic. Group registration will be open from 22 Oct to the end of 7 Nov, 2026.
  • Presentation slots 04.12.2026, are meant only for those who are leaving the country before 07.12.2026.
  • Work on the project. TA session queue is also for project questions.
  • Project report deadline 29.11.
  • FeedbackFruits rubric for the project report
  • Project presentations 4.12 and 7-11.12.

Groups

Project work is done in groups of 2-3 persons. The preferred group size is 3, because you learn more when you talk about the project with someone else.

If you don’t have a group, you can ask other students in the group chat channel #project. Tell what kind of data you are interested in (e.g., medicine, health, biological, engineering, political, business), whether you prefer R or Python, and whether you have already a more concrete idea for the topic.

TA sessions

The groups will get help for the project work in TA sessions. When there are no weekly assignments, the TA sessions are still organized to help with the project work.

Evaluation

The project work’s evaluation consists of

  • peergraded project report (30%) (within FeedbackFruits submission 90% and feedback 10%)
  • presentation and oral exam graded by the course staff (70%)
    • clarity of slides + use of figures
    • clarity of oral presentation + flow of the presentation
    • all required parts included (not necessarily all in main slides, but it needs to be clear that all required steps were performed)
    • accuracy of use of terms (oral exam)
    • responses to questions (oral exam)
      • you should expect questions assessing your understanding of key concepts, your ability to justify modeling choices and your interpretation of the results

Project report

In the project report, you practice presenting the problem and data analysis results, which means that minimal listing of code and figures is not a good report. There are different levels for how a data analysis project could be reported. This report should be more than a summary of results without workflow steps. While describing the steps and decisions made during the workflow, to keep the report readable, some of the diagnostic outputs and code can be put in the appendix. If you are uncertain, you can ask TAs in TA sessions whether you are at a good level of amount of details.

The report should not exceed 20 pages. It may be substantially shorter. The page limit is intentionally generous to allow space for figures and sufficient explanation, but you should use your judgement to filter the most relevant results instead of including all available output from the analysis. If you are uncertain whether your report contains sufficient information, ask TAs.

The report should include

Introduction

Describe the motivation, the problem, and the main modeling idea. In addition, showing some illustrative figures is recommended.

Description of the data

Provide information on where the data was obtained, and whether it has been previously used in some online case study and how your analysis differs from the existing analyses.

Description of the models

We require at least two models to be described. For example: - non-hierarchical and hierarchical - linear and non-linear - different plausible observation models - variable selection with many models

Brief discussion about priors

Provide justification for the choice of priors and whether they are informative or weakly informative. Remember that often you don’t need to spend a lot of time on setting priors.

Code for the models

You can use any of the following tools: brms, rstanarm, Stan, PyMC, Bambi.

Inference details

Describe how you ran the MCMC inference, including the settings and options used. Include the sampling command and explain your choices of settings, such as the number of iterations, warmup, and number of chains.

Convergence diagnostic

Include \(\widehat{R}\), ESS, and divergences, highlighting any problematic values and what can be interpreted from them. There is no need to show a table with all the values (in particular for models with many parameters and without convergence issues); a summary is better. Report what was done to solve convergence issues. This should be reported for all models.

Posterior predictive checks

What can be interpreted from them. What was done to improve the model if the checks indicated misspecification. This should be reported for all models.

You should pay special attention to perform posterior predictive checks appropriate for the type of outcome and the model. For example, using a kernel density estimates (KDEs) for binary outcomes never makes sense. KDEs are suitable for continuous outcomes. They can be used for discrete data if the number of possible values is large enough, but even in those cases consider using suitable alternatives like rootograms. For binary, ordinal, and categorical outcomes, consider calibration plots. See this paper for guidance on choosing appropriate visualizations.

Sensitivity analysis

With respect to prior choices, i.e., checking whether the result changes a lot if the prior is changed. This should be reported for all models.

Model comparison

Compare the predictive performance of the models using an appropriate method, such as PSIS-LOO-CV. Report and interpret the comparison results, including uncertainty in the estimates. Where relevant to the research question, also assess predictive performance using practical measures (e.g., classification accuracy) and discuss their practical usefulness. Explain which model you prefer and why, considering predictive performance, interpretability, simplicity, and alignment with the modeling objectives.

Conclusion and discussion

Discuss the main limitations of the analysis, any issues encountered during the modeling process, and potential improvements to the models or analysis. Summarize the key findings and what was learned from the data, relating the conclusions to the original research question. Reflect briefly on what the group learned while making the project.

For additional guidance, consult the FeedbackFruits rubric for the project report. For guidance on numerical precision and how many digits to report, see the Digits notebook.

Project presentation

In addition to the submitted report, each project must be presented by the authoring group, according to the following guidelines:

  • The presentation should be high-level, but sufficiently detailed information should be readily available to help answer questions from the audience.
  • The duration of the presentation should be 15 minutes.
  • At the end of the presentation, there will be an extra 5-10 minutes of questions. Questions can come from anyone in the audience plus two members of the course staff who are present. Each person in the audience is expected to ask at least one question per slot. The questions from the staff are considered oral exam questions, and if answers to these questions reveal weak knowledge of the methods and workflow steps that should be part of the project, that can reduce the grade.
  • Grading will be done by the two members of the course staff using standardized grading instructions.

Specific recommendations for the presentations include:

  • The first slide should include the project’s title and group members’ names.
  • The chosen statistical models, including the observation model and priors, must be explained and justified,
  • Make sure the font is big enough to be easily readable by the audience. This includes figure captions, legends, and axis information,
  • The last slide should be a summary or take-home messages and include contact information or a link to further information. The grade will be reduced by one if the last slide just has something like “Thank you” or “Questions?”.
  • In general, the best presentations are often given by teams that have frequently attended TA sessions and gotten feedback, so we strongly recommend attending these sessions.

More details on the presentation sessions in 2026

  • Presentations will be given on campus
  • If you reserved a presentation slot but need to cancel, do it ASAP via the reservation link on MyCourses. If you cancel after the reservation link has closed, send a message to Osvaldo Martin (TA) on Zulip.
  • As we have many presentations in each slot join the meeting in time. Late arrivals will lower the grade. Very late arrivals will fail the presentation and can present in period III.
  • It is easiest if just one person from each group shares the slides, but all group members should present some part of the presentation orally.
  • Presentation time is 15 min. Going overtime will not be allowed, and it will reduce the grade. It’s a good idea to practice the talk so that you get the timing right. Staff will announce 2 min and 1 min left, and when time is up.
  • After the presentation, there will be 5min for questions, answers, and feedback.
  • Each student has to come up with at least one question (to other groups) during the session. Students can ask more questions.
  • Staff will ask further questions that can be considered as part of the oral exam.
  • Grading of the project presentation takes into account the following things in the order of importance. You can get feedback for all parts.
    • Students show understanding of essential concepts covered in the course
      • TAs will ask clarifying questions to check these
    • Inclusion of required workflow steps
    • Clarity of the problem, model, and prior description
    • Focus of the presentation
      • Focus on the most relevant points in the limited time
    • Overall clarity and coherence
      • How well the slides and presentation flow
      • Effective presentation of the results
    • Slide design and visual aspects
      • e.g. use of figures, font size, number of digits
      • effective use of figures
    • Lack of typos, grammatical and spelling errors
    • Oral
      • clarity of oral presentation, rhythm and timing, rate of speech
      • clarity of voice projection and appropriate volume
      • presenting style created interest and was engaging
      • presence (e.g. speaking to the audience)
      • possible distracting mannerisms
        • All the points above have a minor effect on the final grade, but staff will point them out so you are aware of them. Involuntary aspects (e.g., ticks) do not affect grading
    • Timing
      • point reduction if overtime
      • fair amount of time for all group members
    • Bonus: going beyond the expectations
      • you may get a bonus point for going beyond the explicit requirements
  • Students will also self-evaluate their project. Instructions for this will be provided.

Data sets

As some data sets have been overused for these particular goals, note that the following ones are forbidden in this work (more can be added to this list so make sure to check it regularly):

  • extremely common data sets like titanic, mtcars, iris, penguins (Palmer Archipelago, n=344)
  • Baseball batting (used by Bob Carpenter’s StanCon case study).
  • Data sets used in the course demos like bodyfat, diabetes, etc.
  • Data sets used in other CS courses.

It’s best to use a dataset for which there is no ready-made analysis on the internet, but if you choose a dataset used already in some online case study, provide the link to previous studies and report how your analysis differs from those (for example, if someone has made a non-Bayesian analysis and you do the full Bayesian analysis).

Depending on the model and the structure of the data, a good data set would have more than 100 observations but less than 1 million. If you know an interesting big data set, you can use a smaller subset of the data to keep the computation times feasible. It would be good if the data has some structure, so that it is sensible to use multilevel/hierarchical models. If you are uncertain, ask TAs.

Here are some public datasets with plenty of choices:

Model requirements

  • Every parameter needs to have an explicit proper prior. Improper flat priors are not allowed.
  • A hierarchical model is a model where the prior of certain parameter contain other parameters that are also estimated in the model. For instance, b ~ normal(mu, sigma), mu ~ normal(0, 1), sigma ~ exponential(1).
  • Do not impose hard constraints on a parameter unless they are natural to them. uniform(a, b) should not be used unless the boundaries are really logical boundaries and values beyond the boundaries are completely impossible.
  • At least some models should include covariates. Modelling the outcome without predictors is likely too simple for the project.
  • brms, rstanarm or bambi (Python) is recommended (less time spent coding the model). brms uses improper flat priors for many parameters, so you need to define proper priors. bambi uses proper priors by default, but they can be too vague in many cases, so you may want to check them.

Report also the proper default priors which you didn’t change.

Some examples

The following case study examples demonstrate how text, equations, figures, and code, and inference results can be included in one report. These examples don’t necessarily have all the workflow steps required in your report, but different steps are illustrated in different case studies and you can get good ideas for your report just by browsing through them.