| Page Properties | ||||
|---|---|---|---|---|
|
Retrospective
| Panel | ||||
|---|---|---|---|---|
| ||||
What did we do well? |
- Planning was good
- Team communication and compromise
- Getting the release out was broken down
| Panel | ||||
|---|---|---|---|---|
| ||||
What should we have done better? |
- Clearly identify the scope of the static assets update ticket. Some members thought that the success of such an update depended upon the success of spec and acceptance tests. Others thought that all test failures should be noted in new tickets, independent of the static assets update ticket. This confusion resulted in several problems:
- Some reviewers ran acceptance tests and rejected the static asset update when tests failed, while others did not run the acceptance tests at all.
- Some reviewers fixed broken tests as part of the static asset update.
- Force-pushes of changes to the static assets overwrote test fixes (which were not expected by the static asset ticket owner).
- Added too many tickets during the sprint