Background
The Sprint objectives covered the following -
Reporting
Opportunities
Gift Administration
Change Management
Statistics at the end of Sprint
Cumulative Flow Diagram
Retrospective
Conducted using IdeaBoardz to collaborate and gather feedback. Participants were given an opportunity to vote on the feedback for discussion.
What went well? | |
Point | Votes |
Stand-up meetings are concise and reflect the work done to advance the Sprint objectives | 4 |
Great team work and collaboration between AQ, Technology, Configuration/ Development, Product Owners, Scrum Master, Project Manager. | 3 |
partnership with AQ team is still going well | 3 |
AQ technical guidance had been great help on building up our knowledge and completed task faster. | 2 |
we picked up speed in sprint 2, higher completion rate this time | 1 |
Happy about the improvement compared to sprint 1. Hoping to happier about Sprint 3. | 1 |
Cross function knowledge really ramped up across the board | 1 |
More used to Jira so the tickets were easier to administer | 1 |
Collaborative work with Product owner to understand the requirement clearer | 0 |
What can be improved? | |
Point | Votes |
In the Sprint Review, maybe config team can present their work- 1/2 user stories per person. And the product owner can cover the remaining. | 4 |
Once a Sprint has commenced, no more User Stories should be added (unless urgent) so that the team can focus on completing the Sprint goal. | 3 |
Longer Retros compared to Sprint Reviews. Retros are where we improve. | 1 |
Making any notes about why decisions or blockers on the JIRA ticket for future reference | 1 |
Faster acknowledgement when assignments are distributed | 0 |
For JIRA ticket a clear notes requires to provide the assignee with the final brief on what need to be done before assign it through. | 0 |
Justifying when a user story is excluded from MVP | 0 |
As we get to know the system better we are making assumptions as to how functionality works - a practical demo with discussion would help | 0 |
Adding simple one liners like "Changing to MVP because so and so" as a comment before changing the status to MVP help. Also the same practic | 0 |
Action items
Action Items | |
Point | Votes |
Sprint Reviews should include Configuration team to showcase/ demo achievements. | 1 |
Document Jira tickets as much as possible with decisions, blockers, actions, etc. (e.g. MVP excl.). Use comments when re-assigning tickets. | 0 |
User stories/ Tasks not related to the Sprint scope shouldn't be added to the Sprint. However, it is ok to add related User stories/ Tasks. | 0 |
As part of User Story refinement, ensure that the Acceptance Criteria is well defined. Config team need to be clear on what to build. | 0 |
