Revision Spring 2026
Drs. Yoder and Hasker
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.
Throughout this document, the term “prose” is used to indicate ordinary speech or writing as distinct from bulleted lists and table formats.
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 the template sprint-report-template.md as a starting point, copying and pasting this as a new wiki page in your project repository.
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.
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). 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.
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.
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.
Give a table showing the status of each PBI worked on during this sprint.
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. The total includes all time, both work on PBIs and ceremonies. Have a column for each team member. There is no need for a total column across the full team.
Each team member is responsible for ensuring their information is entered and is accurate.
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 screenshots of other important items such as working CI systems (including number of tests passing and not passing), user documentation, etc.
Each team member is to describe their contribution to sprint goals:
Number (#nn) and describe the major PBIs to which you contributed and describe for shared PBIs your unique contributions to the PBI. It is not necessary to include titles for PBIs in this section. Your contribution narrative itself may make it clear what the topic of the PBI is. For example, you may write:
I helped Buzz Aldrin adjust the nozzle for the first stage of the rocket (#1).
Even though the title of the PBI isn’t included in this discussion, its topic is clear – and your specific contributions to the creation of the first stage rocket would be clear as well. Include screen shots for your PBI;s. These would be attached using syntax like
[](https://upload.wikimedia.org/wikipedia/commons/9/98/Aldrin_Apollo_11_original.jpg)
It is expected that each team member will be able to document one or more completed PBIs on which they made code contributions. On shared PBIs it can be useful to list not only the PBI number (#nn) but also the merge request number (!nn) in which your contributions were merged into a shared code-base.
For incomplete PBIs, including both the PBI number (#nn) and the merge request number (!nn) could be helpful for partial credit reasons. However, please bear in mind the Scrum perspective that incomplete PBIs should not be considered partial progress for the team. One of the main purposes of the short Scrum cycle is to have real, frequent deadlines and PBIs which are only time-limited should be wrapped up by the end of the sprint so the team can count that 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.
The retrospective MUST have the following sections:
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.
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:
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.
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.
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.
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.