Key Indicator Grading and Retrospective

This review includes requirements from both written and verbal instructions that were provided during Sprint 4. The term “retrospective” in agile development is an opportunity to make things better.

An agile retrospective is an opportunity for agile development teams to reflect on past work together and identify ways to improve. Agile teams hold retrospective meetings after a time-boxed period of work is complete (typically a sprint lasting two to four weeks). During the retrospective, the team discusses what went well, what did not go as planned, and how to make the next work period better.

Team Grading Prep (25 minutes)

This “retrospective” to “ideation” week will be used for teams to improve their work (retrospective) and transition into design (ideation) for the Two Trimester passion projects.

Review Ticket Content. Teams will provide the Teacher with a “Review Ticket” to capture scores, plans, highlight projects, what went well, and what needs improvement.

Utterance Comment. Team review ticket will be an Utterance comment on this blog.

Crossover Grades. Teams / Individuals will crossover grade another team. In the process of development, we often use this type of review to broaden our perspective.

Review Ticket Header

Use the templates below to assist in grading and retrospection with Review Ticket. This Table is an illustrative summary of the most important information between Student development teams and Teacher.

Team

Crossover Score Runtime Plan GitHub Analytics
0.87 Fibonacci Frontend http://127.0.0.1:4100/teacher_portfolio//2023/11/13/CSA-tri2-analysis.html nighthawk_csa Commits

Individuals

Name Team+Indi+Teacher Runtime Issues Key Commit(s) Analytics
John M 1.71=0.87+0.84+? Binary Calculator CORS example SASS buttons, Binary Source Commits, Profile

Crossover Grade (25 minutes)

Teams / Individuals will perform crossover grading.

  • Crossover Scrum Master grading. Scrum Master Team A grades Scrum Master Team B. Place grading in the Header of Review Ticket according to the template. Also, perform individual crossover grading on each other. Be sure to be retrospective.
  • Crossover individual grading. Grade individual by individual (Team A to Team B), if there is an odd person working in a trio. Be sure that I know the name of each grader and who you are grading (i.e., John M grading of Shane L)
  • After grading is complete, Scrum Master or Individuals update scores on top of the review ticket. Scrum Master reviews sources for completeness and makes sure the addition is correct.

Final Grading

Teacher Grading will consider any change to the final 0.1. Note, this would be considered both in meeting guidelines of the project or extra credit.

  • Retrospective improvement. Teams and individuals will have time to make improvements during the week.
  • Indicators in Crossover are final. Do not change scoring after these initial indicators are made. This will be considered “doctoring”,
  • Extra credit. If there are concerns about score, understanding, or completeness in this process… It is possible to add to seed. Individuals will be responsible to come up with action.

Key Indicators Team Template (1 Point)

Grade each checkmark below on a scale of 0 to .9. Total and divide by number of bullets to obtain final score.

Cut Copy and Paste

Team Review "Scrum Master A" grading "Scrum Master B"

- [ ] The team should have a Web Page(s) that teach/explain: Fibonacci, Algorithm, etc.
- [ ] The team should have a Web Page(s) that teach/explain: Sorting, Timing, Compares Swaps, etc.   

Team Review ticket containing key Team and individual contributions
- [ ] Growth/Accomplishments in work is according to historical Team Plan, or they show revisions to plan according to work
- [ ] Short falls/Improvement that could be made in Work or Team Plan, team highlights next steps or improvements that could be made
- [ ] Showing key accomplishments according to requirement in Java Backend such as API, Abstract Class(es), Inheritance, Polymorphic behavior, Sorting Algorithms, etc.  In Sorting, there should NOT be static classes or static methods.
- [ ] Showing key user interaction and learning(s).  For instance how you visualized Sorting Algorithm: Bubble, Insertion, Selection, Merge... how you captured Big O, analytical data, usage of Data Structures...  And/or, how you provided response and Feedback to user on their success in learning or experiencing your interface.

 Per check.  
 0.55 not attempted/no check 
 0.7 attempted, incoomplete, but some runtime
 0.8 mastery and runtime 
 0.9 above and beyond. 

 Freeform comment.  
  Provide positivies and growth summary.  
  Justify or comment on final score.  
  Be sure to provide extra details on anything below 0.7 average or above 0.8.

Key Indicators Individual Template (1 Point)

Grade each checkmark below on scale 0 to .9. Total and divide by number of bullets to obtains final score.

Cut Copy and Paste to Team Review Ticket

Individual Review "My name" grading "Their name"

- [ ] Individual should show that they were key contributor and example to team.  This includes their participation in ideas, plans, creating individual issues, providing code commits to project, crossover grading participation, being on task and positive example in the classroom.

Individuals Video, Issue(s), Commits(s)

- [ ] Video, includes Web demo of key contribution to project, 1 minute
- [ ] Issue(s) that show plans/progress to team objectives
- [ ] Highlights of key commit(s) in Issues, summarizes code contributions
- [ ] Review GitHub analytics for key commits in each weeks during the project, shows consistent participation for 3 weeks

 Per check.  
 0.55 not attempted/no check 
 0.7 attempted, incoomplete, but some runtime
 0.8 mastery and runtime 
 0.9 above and beyond.

 Freeform comment.  
  Provide positivies and growth summary.  
  Justify or comment on final score.  
  Be sure to provide extra details on anything below 0.7 average or above 0.8.