Sprint Goal / Focus
- Tie up loose ends, and prepare ground for Q3.
Sprint Schedule
- Sprint: 66
- Quarter: 2019 Q2
- Start Thursday 13 June, 2pm UK
- Finish Friday 28 June, 2pm UK
- Retrospective: Wed 3 July, 2:30pm UK
Sprint Capacity
Team Availability: Schedule
Notes / Exceptions:
- 17-20 Jun FOLIO Washington + Travel (Ian, Owen, Jag)
- Claudia Malzer not available after 19 June
- md331 (Deactivated) not available 13-14 June
- Peter Böhm only available 13, 14, 19 June
Lead Roles:
- Front End Code Review: md331 (Deactivated)
- Back End Code Review: steve.osguthorpe
- QA: Owen Stephens
QA Environment: folio-testing
Navigation
Sprint Planning
- not in sprint
or @ - in sprint
| Feature ID | Issue ID | Sprint Backlog? | Notes / Estimates / Actions |
|---|---|---|---|
UXPROD-1511 - Getting issue details... STATUS | ERM-269 - Getting issue details... STATUS | BE 0h FE 8h TODO: differences in SASQ routing from Licenses to Agreements, so slightly different. Aditya matukumalli to support Claudia Malzer on accomodating the differences. Expected to be complete by end of week. | |
ERM-253 - Getting issue details... STATUS | |||
ERM-254 - Getting issue details... STATUS | BE 15h FE 0h Driven by https://folio-project.slack.com/archives/CAYCU07SN/p1557421022302700
Explainer documentation in Github. Dev questions raised as tasks/bugs in Jira. Peer review by dev team. | ||
ERM-276 - Getting issue details... STATUS | |||
UXPROD-1517 - Getting issue details... STATUS | ERM-265 - Getting issue details... STATUS | Carried forward. Remaining: BE 8h FE 0h. Controllers and servers are in place. Some potential reuseable code in stale branch for MODERM-23. TODO:
| |
UXPROD-1643 - Getting issue details... STATUS | ERM-182 - Getting issue details... STATUS | BE 2h FE 0h. Feeds into a piece of work around data integrity. Requirement is still to validate a coverage statement, but not reject it:
Output of this is to introduce the mechanism to not fail the import for recoverable errors. Logging of errors should be done in a way that can be easily reported to user, but is out of scope (see, eg ERM-183 - Getting issue details... STATUS for logging, and ERM-217 - Getting issue details... STATUS for presenting.) | |
UXPROD-1597 - Getting issue details... STATUS | ERM-268 - Getting issue details... STATUS | ||
UXPROD-1302 - Getting issue details... STATUS | ERM-190 - Getting issue details... STATUS | Carried forward | |
ERM-193 - Getting issue details... STATUS | Carried forward | ||
UXPROD-1159 - Getting issue details... STATUS | ERM-274 - Getting issue details... STATUS | ||
UXPROD-1517 - Getting issue details... STATUS | ERM-215 - Getting issue details... STATUS |
| BE ?? FE 0h. Some potential reuseable code in stale branch for MODERM-23. To complete Scenarios 1 and 2, but not Scenario 3. Should this even be an ERM job? OKAPI authentication is project-wide.
|
UXPROD-1601 - Getting issue details... STATUS | ERM-230 - Getting issue details... STATUS | ||
UXPROD-1159 - Getting issue details... STATUS | ERM-277 - Getting issue details... STATUS | ||
UXPROD-1159 - Getting issue details... STATUS | ERM-278 - Getting issue details... STATUS | ||
ERM-261 - Getting issue details... STATUS | Carried forward. |
To Carry Forward
| Feature ID | Issue ID | Sprint Backlog? | Notes / Estimates / Actions |
|---|---|---|---|
UXPROD-1157 - Getting issue details... STATUS | ERM-239 - Getting issue details... STATUS |  | |
UXPROD-1157 - Getting issue details... STATUS | ERM-240 - Getting issue details... STATUS | | |
UXPROD-1157 - Getting issue details... STATUS | ERM-242 - Getting issue details... STATUS | | Requires ERM-239 - Getting issue details... STATUS
steve.osguthorpe Should the backend provide the data, or should the frontend fetch this (as done with organizations)? |
UXPROD-1751 - Getting issue details... STATUS | ERM-273 - Getting issue details... STATUS | |
|
