Fall 2026 (and later)

This document was written by Dr. Yoder and Dr. Hasker with input from other faculty.

Sprint Review and Retrospective

The Sprint Review and Retrospective Report summarizes what portion of your sprint goals were completed (the “review” portion) as well as how your team performed in achieving those goals (the “retrospective” portion). Prepare this document carefully! Be sure this document makes it obvious what you and the team accomplished and how the process will improve in the next sprint. Screen shots capturing your progress are critical. Consider including screen shots of other important results such as establishing a continuous integration (CI) system or meeting a code coverage milestone. This document provides evidence of your accomplishments and is a major part of each sprint’s grade. It is also intended to be a record that you could show to prospective employers. Do not have an LLM write your report for you! This is a critical document, and if genAI writes it for you then important things may be missed or described poorly.

Throughout this document, the term “prose” is used to indicate ordinary speech or writing. Alternatives to prose included bulleted lists and tables.

The report will have multiple sections. All sections must be combined into a single report even if you have different meetings for different sections. Use this template as a starting point, copying and pasting this as a new wiki page in your project repository. Be sure to remove all PLACEHOLDER items in the document before submitting it!

Note that primary material must be in the document. Do not link to other documents unless the link is just a footnote to something that is not important to your grade. This document is a key portion of the assessment for this course, and links are too volatile.

Review

In this section, review the completed functionality. The primary focus should be on story PBIs since completing stories represents real progress, but include other high-level PBIs (defects, knowledge acquisitions, internal improvements, etc.) that have also been completed. There should be screen shots capturing evidence of what was completed. In most cases the screen shots will be of your running application, but you might also capture test results (say, to show faults or build scripts were fixed). Keep the screen shots focused; include enough to show what was accomplished, but avoid including redundant information. You may also be required to demonstrate your progress to your instructor.

The review MUST have the following sections:

You are welcome to include additional sections, but any new sections should be after the others listed above.

Sprint Goal

Restate the sprint goal. Do not mention individual PBIs in this section but rather focus on the themes that motivate the majority of the PBIs. The goal should be a single sentence.

Burndown

Present your issue-weight burndown chart in your report as the basis for the items that follow. If you find them relevant, you can also include an issue-count burndown chart and/or burnup charts.

Discuss any abnormalities in the chart (such as spikes or burn-cliffs) and what you think the sources of those abnormalities are. See the note in the sample template about including work done the evening before the end of the sprint.

PBI Status Report

Give a table showing the status of each PBI worked on during this sprint.

Hours Worked

Give a table capturing the time spent by each team member on each PBI. The time is to be listed to the closest tenth of an hour. That is, if you work 3 hours and 40 minutes, list it as 3.7 (rounding up from 3.666). This table must include a row for each PBI as well as a rows for ceremonies and totals. Some notes on this table:

If hours differ significantly from what is reported by AboutTime, team members must include an explanation adjacent to this table explaining why the numbers differ from those reported by online tools like AboutTime. If a team member’s hours were significantly less than expected for a sprint, the team member may wish to add an explanation. You must receive permission to include time outside the sprint start and stop dates in a particular report.

Close this section with a short paragraph describing the overall state of the product. This question is largely about what has been merged into the dev branch, but at times you might wish to discuss staging or main branches as well.

You may optionally include screen shots of other important items such as working CI systems (including number of tests passing and not passing), user documentation, etc.

Individual Contribution Reports

Each team member is to describe their contribution to sprint goals:

Create a list of PBIs (in outline form) for which you made major contributions during the sprint. These can include PBIs that were started in a previous sprint or will be continued in the following sprint, but make it clear what portion of the PBI was done in the sprint being reported on.

For each, give the GitLab PBI identifier (a number) and its description. Describe what you accomplished on the PBI, typically in prose format. For most PBIs, there should be a screen shot showing the new feature in action. If the PBI is about design, include design artifacts such as wireframes or UML diagrams. If the PBI is about building or testing, include a screenshot showing that the system built, tests were run, and that there were no errors. The overall idea is to capture evidence of what you accomplished. To include an image into markdown, follow this example:

[![Buzz on the Moon](Buzz.jpg "Buzz Aldrin on the Moon")](https://upload.wikimedia.org/wikipedia/commons/9/98/Aldrin_Apollo_11_original.jpg)

The core idea is to provide evidence that the PBI was completed to a “done-done” state.

If more than one person worked on a PBI, focus your documentation on what you accomplished and write a sentence or two documented who else worked on the PBI and how they contributed.

If a PBI is not complete, put it at the bottom of your list and indicate what portion of the work is done. In that case it is unlikely useful to include evidence. Scrum focuses on work done, not work partially done, but in a classroom environment it can be good to document this sort of work-in-progress.

Discuss your role in reviews, especially cases in which you identified issues that needed to be resolved before accepting the merge request. Include merge request numbers (!nn) in these cases.

State your team role (product owner proxy, ScrumMaster, note taker, devops lead, etc.) and document activities you have done in support of your role. Be sure to go beyond restating definitions! Give enough specifics so that I or a hiring manager could understand how capably you filled your role. Consider including such details as dates, circumstances involved, and outcomes.

If your accomplishment is a spike solution that will not be pulled into the product, note that the spike solution must have a report associated with it. Be sure to link that report into the sprint review document. This type of link is an exception to the above rule about not using links, but it is appropriate in this case. Include a title with the link in case the document is moved at a later date.

Sprint Retrospective

The retrospective MUST have the following sections:

Progress and Velocity

Briefly discuss your progress through the sprint. This will likely include information from weekly standups and other Scrum ceremonies, but should not be an exhaustive week-by week summary. Focus on themes and trends in progress.

Compare your planned progress against your actual progress. This should start by comparing the target number of story points against the delivered number of story points, but could include discussions of process issues that slowed progress.

Analyze your team velocity based on story points completed. Starting in the second story-pointed sprint, this should number exactly how many story-points were completed for each of the last two sprints and list the average velocity. More sprints can be included if desired. Give and defend the story point target for the next sprint. If this story point target is not within the range of 20 to 30 points, discuss this with your instructor.

Process and Process Improvement

Discuss the software quality activities and tasks your team practiced in this sprint (including design reviews, code reviews, unit tests, test plans).

Discuss improvements your team has made to your software development process, including any changes you made to reduce technical debt (such as automating your team’s testing and build processes).

Early in the project, discuss the groundwork you are laying for good process. There is no need to mention that you don’t have a process to improve yet.

Add additional sections as needed. You might consider discussing tasks which were either over or under estimated by large amounts, project pivot reports, cumulative flow diagrams, epic reports, control charts, etc.

If you engage in an activity (such as dot voting) as part of your retrospective, include notes from that activity and discuss the results.

Close with discussions of what went well, what could be improved, and process-related action items assigned to specific team members:

What did we do well?

List items you did well. Give some detail; for example, don’t just say “estimated well” but briefly discuss how your process lead to good estimates.

What should we have done better?

List all the items you should have done better. For example, describe the sorts of tasks you had difficulty estimating or the stories that exhibited poor communication. Attempt to identify causes.

Actions

Identify process improvements, giving specifics about how you will address each. Ensure these are measurable. For example, set a goal of completing X% of tasks within 20% of the estimated time or moving a third of the story points to DONE each week. @mention team members with assigned process-improvement tasks.

Publishing the Review and Retro Report

Use the template to write your report, including filling in the title information (such as sprint report titles, team members, and sprint dates). Ensure that all placeholder text has been removed before publishing the final version.