- Complete sprint
- Determine if sprint goals were met
- Discuss completed items
- Demo any necessary items
- Decide what to do with any item not completed
Support Team Discussion Items
Technical Discussion Items
What did we do well / What did we learn?
What should we have done better?
What should we start doing?
What should we stop doing?
What should we keep doing?
Developer Discussion Items
warning or error?
Jira server SSDT JIRA serverId 925ea1db-0df8-3e91-bcfb-6b1c8a04f6ca key USPSR-3624
- Producing a warning should be ok for now
- (Justin) UAT - Should docks on advanced compensations even be allowed?
- (Andy) UAT - Should advance reports be disabled while in advance? Currently the button to generate a submission file is disabled while in advance, but the report buttons remain enabled.
- Discussed with UAT - Issue added
Jira server SSDT JIRA serverId 925ea1db-0df8-3e91-bcfb-6b1c8a04f6ca key USPSR-5036
Jira server SSDT JIRA serverId 925ea1db-0df8-3e91-bcfb-6b1c8a04f6ca key USPSR-5018
- Discussion on the account sync issue
- (Justin) UAT - Should users be able to manually turn advance mode on/off in the configuration?
- Discussed with UAT, will look into making this prop read only if NOT in advance mode
- (davis) Audit Report discussion
- Per priority committee, the Audit report will be moved to 6.11.0 - 6.12.0
Jira server SSDT JIRA serverId 925ea1db-0df8-3e91-bcfb-6b1c8a04f6ca key USPSR-5031
- (Greg) Ticket came in where user was unable to add a Contract compensation manually via Current due to a 'unit amount cannot be zero' error. Turns out there was an archived NonContract compensation that was actually the source of the error. Should we ignore archived compensations? Or at the very least, give preference to non-archived compensations?
- (Greg) Both Ryan McClay and myself have noticed error messages in the server logs that seem problematic to me:
Jira server SSDT JIRA serverId 925ea1db-0df8-3e91-bcfb-6b1c8a04f6ca key USPSR-5033
- (Greg) Do we need to provide a way for USPS-only districts to bypass the externalId validation?
Jira server SSDT JIRA serverId 925ea1db-0df8-3e91-bcfb-6b1c8a04f6ca key USPSR-5038
- (Andy) Soap bridge - queryPositionsById - supposed to return all positions for a given employee number that is passed in as a parameter. Currently uses a 'like' query to find positions with position.employee.number like the passed number. If a number such as '2233' is passed in and there is an employee with number = 2233 and also an employee with number = 22334455, positions for both employees are returned. A kiosk district reported that a situation similar to this resulted in not all positions showing up for the employee with the 2233 number. The kiosk apparently does not cope with positions for multiple employees being returned by this soap call. They are expecting only positions for the employee who's number they provide. We would need to update the soap bridge method to use = instead of 'like'
- This is currently preventing one employee from submitting leave in the kiosk. Informed the kiosk developers of what we are currently returning and told them they could search the results for the correct employee. They are not making the update at this point because they believe our service is returning incorrect results.
- Issue added
Jira server SSDT JIRA serverId 925ea1db-0df8-3e91-bcfb-6b1c8a04f6ca key USPSR-5047
- (Justin) Tax Estimator
- Handling multiple compensations with different retirements or a job with no retirement
Jira server SSDT JIRA serverId 925ea1db-0df8-3e91-bcfb-6b1c8a04f6ca key USPSR-5002
- Average velocity for USPS-R team: 8 story points
- Clarify team availability
- Add user stories and bugs to the next sprint
- Make sure each story / bug is clear
- Estimate each story / bug
- Create sprint goal
- Start sprint