Attention: Confluence is not suitable for the storage of highly confidential data. Please ensure that any data classified as Highly Protected is stored using a more secure platform.
If you have any questions, please refer to the University's data classification guide or contact ict.askcyber@sydney.edu.au
Sprint 1 - Configurations Retrospective
- Brad Fernandes (Unlicensed)
Date | Sep 22, 2020 |
|---|---|
Team | Configuration/ Development, Product Owners, Affinaquest |
Participants | @AlainGasquet@alexia nicholson (Unlicensed) @apirami.kumaradevan @Brad Fernandes (Unlicensed)@Dev Subramanian (Unlicensed)@Griffin Homan (Deactivated) @Jules Levin@Manpreet Sidhu @Monica Kluegel@Rachel Forbes @Sidra Zafar@The Ho Trang @Trevor Lindsey (Deactivated) @Yeng Sembrano |
Background
The Sprint objectives covered 2 key areas -
Biographic & Notifications
Reporting
Statistics at the end of Sprint Review
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 |
Daily progress report by Brad and his dashboard gives a better overall view of our progress, keeping us more updated | 4 |
Availability of AQ team when facing blockage. | 4 |
Testing by product owners right after configuration kept the momentum making development faster | 3 |
Great collaboration with AQ developers. Their support made configurations faster and less complex for beginners like us. | 2 |
Great team work between Product Owners and Development team | 2 |
great collaboration between developers, POs and AQ in the JIRA tickets | 2 |
it was easy to get in tough with AQ for support | 1 |
Importance of standup to check if we are all in same page / flag blocks | 1 |
Good enough support from AQ team for configuration in Salesforce. | 1 |
Good communication between team members | 1 |
Learning about Salesforce configurations was made easy by Griffin and Trevor. Thank you and Please continue supporting us the same way. | 1 |
I enjoyed the stand-ups where everyone got an equal opportunity to discuss their activities to advance the Sprint goals. | 0 |
Good grooming of user stories | 0 |
User adoption of the core team seems to be quite high with a good attitude towards the process as a whole. | 0 |
The intro technical session with tech guide through area of works was very useful. Also one on one are helpful too | 0 |
Standups were great at keeping everyone informed of progress | 0 |
Developers quickly picked up what was required and velocity increased as sprint progressed making great progress on the backlog | 0 |
Limiting standup time and control of the meeting cadence | 0 |
Thanks to product owner for a fast testing as it's good to pick up issues if there is any. | 0 |
What can be improved? | |
Point | Votes |
User stories similarities between sprint groups may generate unnecessary work / or worse contradictory requirements | 5 |
Decision criteria for sprint distribution are unclear | 5 |
Notifications on Jira sometimes are very heavy and it may be difficult to monitor action items / questions from others | 4 |
user story consolidation - remove duplications | 4 |
User story grooming is tricky...perhaps more heads are better than one! | 3 |
New tickets were added in the middle of the sprint | 2 |
At the Stand-up, the updates should be short. Any detailed discussion should be left for 'After-meeting'. | 1 |
The product owner of the sprint gets most of the tickets for testing which I think is overwhelming for one person to do most of the testing | 1 |
Clearer communications between USYD and AQ about what is expected when a JIRA US is passed on ie only advise or configure. | 1 |
Make greater use of Trevor's time to get more done in the sprint. | 1 |
Not work in the middle of the night. | 0 |
Not all tasks are well defined | 0 |
If it's possible to control the frequency of JIRA email updates, maybe batching many updates into one, that'd be great! | 0 |
The developer's focused is being divided because aside from configurations we have the data migration testing to think of. And thus some of our tickets, we had to reassign to AQ. We had no time to linger on it a bit longer and learn it more. | 0 |
Sometimes difficult to track where your work in Jira was when we were using comments | 0 |
It would make things easier for the developers if there is one screen where we can see all the tickets assigned to us irrespective of .... A | 0 |
Not sure about the rest of Devs but I would really like to have a separate stand-up for Dev team with Griffin and Trevor | 0 |
A.... its type, like Zephyr or User Story or Retest. | 0 |
Some tasks were assigned for later sprints, and created a bit of schedule confusion | 0 |
The level of details of user stories are inconsistent. Very broad too very limited. Maybe not ideal | 0 |
Data availability as this was to blocker to data conversion testing | 0 |
If we had a way to assign both the CSM and the Developer to the ticket to see the progress of the ticket after we have reassigned it | 0 |
duplicates were confusing | 0 |
I think we need to have the SME of the area to involve in the testing beside product owner to testing for second eye of checking | 0 |
Action items
Action Items | |
Point | Votes |
create a dashboard in Jira for the development team | 0 |
when creating User stories, breakdown the user stories across the different sprints. | 0 |
check if there is a way to group Jira notifications on a periodic basis. | 0 |
share the IdeaBoardz before the Retrospective. | 0 |