Showing posts with label rubrics. Show all posts
Showing posts with label rubrics. Show all posts

Monday, October 20, 2014

Managing Student Peer- and Self-Evaluations using Google Forms

I have written before about the rubric I use for students' self- and peer-evaluation. Here is the latest version that I have deployed this semester, copied from my 2011 post.

3210
Commitment Attended all scheduled team meetings or notified the team of absence. Missed team meetings, with notifications, with enough regularity to be problematic. Missed one or more team meetings without notifying the team. Regularly missed team meetings without notifying the team.
Participation Contributed to project planning, implementation, testing, and presentations. Did not contribute to one of the following: project planning, implementation, testing, and presentations. Did not contribute to two of the following: planning, implementation, testing, presentation. Did not contribute to three or more of the following: planning, implementation, testing, presentation.
Communication Clear reports on what has been accomplished, what is in progress, and what stands in the way, thereby facilitating progress. Sometimes is unclear about what has been done, what is in progress, and what stands in the way, creating minor impediments to progress. Is regularly unclear about what has been done, what is in progress, and what stands in the way, creating significant impediments to progress. Communication patterns directly disrupt team progress.
Technical contributions High quality technical contributions that facilitate success of the team. High quality technical contributions that do not directly facilitate the team's success. Low quality technical contributions that frequently require redress by other team members. Low quality technical contributions that inhibit success.
Attitude and Leadership Listens to, shares with, and supports efforts of others, and actively tries to keep the team together. Listens to, shares with, and supports the efforts of others. Frequently fails to listen, share, or support teammates. Displays an antagonism that inhibits team success.


I have been conducting the evaluations on paper and transcribing the data into a spreadsheet for analysis. I realized last academic year that the analog form was preventing me from using self- and peer-evaluations more frequently. I suspect that if teams had to give and receive this feedback more regularly, more teams would be able to identify and mitigate collaboration problems. I decided to require self- and peer-evaluations for each iteration of my Game Programming and Advanced Programming courses, in part to push me to explore a streamlined, digital solution.

My first stop was Blackboard, which is required at my university at least for entering students' final grades. I found no support for the kind of group-restricted peer evaluations that interest me.

Enter Google Forms. If you have not used this before, it is an easy-to-use tool for creating forms, distributing them, and analyzing the results via integration with Google Sheets. I created a template that converts the tabular rubric into a series of five questions on a zero-to-three scale. To use the form for any particular class, I copy the list of student identifiers from Blackboard and paste them into the first two questions—the selection of the evaluator and the subject under evaluation. I could not find a way to make the template publicly readable without also making it publicly editable. If you want to try the form yourself, contact me and I'll share it with you via Google Docs, then you can make your own copy of it.

Once the students have completed the form, I use a pivot table to summarize the results. Specifically, I add a row for the subject of evaluation ("evaluatee"), then add values for the five rubric categories, summarizing by median. The pivot table is itself a sheet, and so I can add a new column that sums the medians to reach a student's contribution score.

Getting this information back to the student is still a manual process. My current approach is to make a new column in Blackboard's grade book and then sort the grade book table by student identifier to match the sequence in the pivot table. I step through, student by student, entering the contribution score and, in the comments field, the five medians in a simple, space-separated format. While this is somewhat tedious, it does force me to look at each line and identify whether I should intervene with a team or an individual.

The form cannot validate that each student completes the form exactly once for each peer. Another quick pivot table makes this easy to verify, however: add a row for each evaluator and a column for each evaluatee, add the evaluatee data, and summarize by "COUNTA". Anyone who has submitted more than one evaluation of the same person will be notable in the table, and each row's total should be the number of person in that student's team. This technique allowed me to recognize that a few students submitted multiple evaluations of a partner, presumably by mistake since the data matched up.

This approach presumes that students will be honest in identifying themselves, but the whole self- and peer-evaluation system already presumes honesty. I talk to my students about this, that I assume they will be honest with me because I have been honest with them.

Hopefully these notes will be useful to others who are thinking about how to conduct peer evaluations. If nothing else, this will help me remember how I handled the first iteration so that I can replicate it in the second!

Friday, November 11, 2011

Rubric-based self- and peer-evaluation on team programming projects

I have written before about grading rubrics, and I am taking this opportunity to share some of my recent developments here. In my game programming class (CS315), I have eleven students working together on one project. We're using Scrum, and it's still going well. The early part of the semester was ungraded, formative, small-project work, and I found myself needing a way to assign grades to the students. It may be worth mentioning that I don't actually want to assign grades to them, but it is a requirement of the course, and so I must do it responsibly.

I happened to stumble across a rubric I created in 2008, before my blogging days, while I was cleaning up my Web space. As I recall, this was an amalgam of several other rubrics I had found on the Web with an ounce of invention. This was my inspiration to create the following rubric:

3210
Commitment Attended all scheduled team meetings or notified the team of absence. Missed team meetings, with notifications, with enough regularity to be problematic. Missed one or more team meetings without notifying the team. Regularly missed team meetings without notifying the team.
Participation Contributed to sprint planning, sprint review, and sprint retrospective meetings. Did not contribute to one of the following: sprint planning, sprint review, or sprint retrospective meetings. Did not contribute to two of sprint planning, sprint review, and sprint retrospective meetings. Did not contribute to any of sprint planning, sprint review, and sprint retrospective meetings.
Communication Clear standup reports on what was accomplished, what is planned, and identification of impediments, to allow the team to continue to make progress. Some unclear standup reports that inhibit team progress. Regularly unclear standup reports that inhibit team progress. Did not give standup reports.
Technical contributions High quality technical contributions that facilitate success of the team. High quality technical contributions that do not directly facilitate the team's success. Low quality technical contributions that frequently require redress by other team members. Low quality technical contributions that inhibit success.
Attitude and Leadership Listens to, shares with, and supports efforts of others, and actively tries to keep the team together. Listens to, shares with, and supports the efforts of others. Frequently fails to listen, share, or support teammates. Displays an antagonism that inhibits team success.

I created this after the team's first sprint, and parts of it are reactions to problems the team was having. For example, in the team's first sprint retrospective, they identified that many had spent inordinate time on aesthetic issues that were unrelated to the user stories. Hence, there is a distinction between those technical contributions that facilitate success and those that do not. Note that the numbers across the top relate to my triage grading approach; some day I will write a blog post about my experiences with it, but for the time being, suffice it to say A=3, C=2, D=1, F=0.

I shared this rubric with the team during Sprint 2, and at the end of the Sprint, I asked each person to do a personal evaluation. This was designed as a formative evaluation for the student as well as a trial run of the rubric. From reading the students' self-evaluations, I think the instrument worked as intended, and we're going to do self- and peer-evaluations at the end of this sprint.

In my other course (CS222), students are working in teams of four on six-week projects of their own design. They just finished their mid-project milestone presentations, and I've modified and distributed the rubric to this other group as well. I've highlighted those cells that have changed.

3210
Commitment Attended all scheduled team meetings or notified the team of absence. Missed team meetings, with notifications, with enough regularity to be problematic. Missed one or more team meetings without notifying the team. Regularly missed team meetings without notifying the team.
Participation Contributed to project planning, implementation, testing, and milestone presentations. Did not contribute to one of the following: project planning, implementation, testing, and milestone presentations. Did not contribute to two of the following: planning, implementation, testing, presentation. Did not contribute to three or more of the following: planning, implementation, testing, presentation.
Communication Clear reports on what has been accomplished, what is in progress, and what stands in the way, thereby facilitating progress. Sometimes is unclear about what has been done, what is in progress, and what stands in the way, creating minor impediments to progress. Is regularly unclear about what has been done, what is in progress, and what stands in the way, creating significant impediments to progress. Communication patterns directly disrupt team progress.
Technical contributions High quality technical contributions that facilitate success of the team. High quality technical contributions that do not directly facilitate the team's success. Low quality technical contributions that frequently require redress by other team members. Low quality technical contributions that inhibit success.
Attitude and Leadership Listens to, shares with, and supports efforts of others, and actively tries to keep the team together. Listens to, shares with, and supports the efforts of others. Frequently fails to listen, share, or support teammates. Displays an antagonism that inhibits team success.

These students are not using and are not familiar with Scrum, and so the Scrum-specific references needed to change. I am not that happy with the articulation of participation above, in part because we invested a lot of time on test-driven development, and I fear the students will be confused about separation of testing and implementation. The "communication" entry is clearly influenced by the idea of the Daily Scrum, but I have not previously suggested this particular reporting strategy to the students.  My hope is that by asking them to conduct rubric-based self- and peer-assessments, they will gain some insight into better ways to organize themselves. As with the game programming students, I am using this first pass as a formative assessment, and also as an instrument to help me identify teams that are having problems with team members—an unfortunate but oft-inevitable situation.

The students in CS222 had their first group experience with rubric-based evaluations this week when they evaluated each others' milestone presentations using this instrument:

Presentation requirementSatisfactory (3)Probationary (2)Unsatisfactory (1)Unacceptable (0)
Executable release Stable and appropriate demo of executable release Unclear demonstration of stable executable release Unstable executable release No demo
Milestone #1 Estimate Clearly met milestone estimates Clearly met a reasonable subset of milestone estimates Did not meet an adequate subset of milestone estimates Progress on initial estimates was not addressed
Milestone #2 Estimate Clear presentation of well-articulated estimates for next milestone Clear presentation of poorly-articulated estimates for next milestone Unclear presentation of poorly-articulated estimates for next milestone Milestone #2 estimates not addressed
Software architecture Good presentation of reasonable software architecture Decent presentation of reasonable software architecture Unclear or awkward software architecture No presentation of software architecture

I printed these on small slips of paper. On Tuesday, we had four presentations, so I instructed the students to pick up four slips as I talked through the structure and purpose of the rubric. On Thursday, we had five presentations, so I left the slips in the same place in the back of the room and I put on some mood music.


I was a little disappointed that none of them stopped to tell me how incredibly clever this was.