Sprint Review

Sprint Goal

PLACEHOLDER: Restate the sprint goal and relate it back to the project as a whole. No need to mention PBI numbers in this section.

Burndown

PLACEHOLDER, burndown charts: the weight-based (that is, story point) burndown. The team may add other burndowns if they find them useful. Add discussions for any anomalies as well. For example, explain increases in story points or why there was a long period with no stories completed.

PBI Status Report

PLACEHOLDER: Insert a table with the format shown below. In this table, PBI should be the PBI identifier for your project (where possible, link to the project PBI itself), the Description should be a shortened form of the full PBI text, and Status should be complete, not started, started, or deleted. Sort PBIs by their identifier.

|——————|————————————————-|————-|

PLACEHOLDER: Discuss the current state of the project overall; if you had to deliver at the end of the sprint, what would be delivered?

Hours Worked

PLACEHOLDER: Insert a table showing hours worked on each PBI for each team member. For each PBI, give its identifier and a few key words from its title. Abbreviate so the description fits in a single row. List members in alphabetical order by last (family) name. Time is to be listed to the nearest tenth of an hour. If you prefer, you can build the table in a spreadsheet and copy/paste it into this document.

|——————|——|———|———|———|———|

PLACEHOLDER: Discuss significant discrepancies from time reported in AboutTime

Individual Contributions

PLACEHOLDER: This section will discuss contributions by each team member by PBI. List team members by order of last name, but include both first and last names as section headers. If more than one person works on a PBI, give detail in one entry and refer to that (clearly) from other entries.

Member1 (PLACEHOLDER)

PLACEHOLDER: Discuss the contributions by this student in a bulleted list ordered by PBI. For each, give the PBI identifier and PBI description (linking the PBI identifier to the actual GitLab PBI), identify the branch on which the work was done, the merge request merging it to the appropriate upstream branch, and a discussion of any significant problems solved along the way.

PLACEHOLDER: Almost all PBIs should include visual evidence of completion. For features, include screen shots of the feature from the user’s point of view. For internal improvement PBIs, include evidence of completing the PBI such as a revised UML diagram, metrics showing improvements (for example, an increase in code coverage), and updated configuration diagrams. Knowledge acquisition items should both link to the full report in the project wiki and include a short paragraph capturing what was done and what was found. Keep any screen shots focused, capturing enough context for the key information so that your instructor can understand what was completed but not including lots of empty space that forces text into small fonts. All images need titles or other explanatory text.

PLACEHOLDER: After listing completed PBIs, include a bullet describing your other efforts during this sprint, such as work on incomplete PBIs or particular contributions to scrum ceremonies and artifacts.

PLACEHOLDER: As a final item, name your scrum team role and describe the work you did in that role during the sprint.

Member2 (PLACEHOLDER)

PLACEHOLDER: Same as Member2

Member3 (PLACEHOLDER)

PLACEHOLDER: Same as Member3

Member4 (PLACEHOLDER)

PLACEHOLDER: Same as Member4

Sprint Retrospective

Progress and Velocity

PLACEHOLDER: Discuss your progress through the sprint at a high level.

PLACEHOLDER: 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. PLACEHOLDER: Analyze your team velocity based on story points completed for the last two sprints, including this one. List the average velocity. Give and defend the story point target for the next sprint.

Process and Process Improvement

PLACEHOLDER: In one or more paragraphs, discuss your team’s experience with process in this sprint. Evaluate the software quality activities and tasks your team practiced in this sprint including design reviews, code reviews, reduction of technical debt, unit tests, and test plans. Discuss the state of testing of your product with a focus on automated testing. Review the process improvement goal for this sprint and evaluate the teams progress on that goal.

PLACEHOLDER: 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.

PLACEHOLDER: 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.

PLACEHOLDER: 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. Since attempting to fix everything at once usually leads to frustration, this list will likely be a subset of the items you could have done better.