Goals
| Goal | Accomplished? | |
|---|---|---|
| 1 | Validate, load and adjust data model as generated by ICDC::MakeModel | Yes |
| 2 | Visualize data model in Gen3 | Yes |
| 3 | Adjust UI for Gen3 (Windmill) | Yes |
| 4 | Transform and load some C3D clinical data (Amit submits TSVs) - one dog across all nodes (Molly) | Halfway - break into two goals |
| 5 | Validate data loading by searching/visualizing data | No |
| 6 | Take model and impose initial data constraints (add properties). | No |
Retrospective Results
| Author | Category | Card Title |
|---|---|---|
| Philip M | What Worked | Mark's "publication" of the latest data model iterations in visual form via Slack was really helpful during the assembly of the Excel-based transformations. |
| Philip M | What Worked | Short, repeated, face-to-face data model iterations were extremely helpful in terms of aligning and reconciling data transformations with the data model. The inherent "nit picking" was time well spent. |
| Matthew B | What Worked | Philip spent a lot of time working out how to do transformations with the help of Mark and Ye. Good team work! |
| Matthew B | What Worked | Sprint planning (for next sprint) was productive and set short-term and long-term goals. |
| Philip M | What Worked | Excel-based transformations, as tedious, error-prone and time-consuming as they were, have ultimately provided a means by which to spin off the appropriate txt/tsv files as needed, which was the primary goal, and simultaneously benchmarked the transformation process before us investing time in a Pentaho-based strategy. |
| Philip M | What Didn't Work | Being 100% reliant upon Mark to make micro-updates to the data model. We need to alleviate a costly and unnecessary bottleneck by opening up GitHub across the team, agreeing upon our process around using it, and making the model-defining YAML file accessible for modification independent of Mark. He has bigger, more important fish to fry. |
| Matthew B | What Didn't Work | We seemed to spend a lot of stand-up time getting bogged down in technical details. |
| Philip M | What Didn't Work | Stand up calls tend to lack structure and direction, and don't focus upon upward and outward communication of specific progress updates from those doing the work. |
| Matthew B | What Didn't Work | In general, tickets are not moving throughout the sprint. Comments need to be added and tickets need to move through the workflow. |
| Matthew B | Suggestions for Improvement | Team members should pro-actively enter tickets in backlog related to their areas. Epics, story points and components associated should be completed. This will facilitate the sprint planning process by providing a starting point - tickets can be edited as needed during the planning meeting. |
| Philip M | Suggestions for Improvement | In my opinion, stand up meetings need to be driven by the sprint board, and be focused upon the issues being actively worked upon. Each team member needs to be given an opportunity to report "done, doing, next and impediments/blockers" during each stand up, and the order in which updates are reported should cycle through the team. Updates should reference the tasks in hand, and the information flow should be upwards and outwards. |
| Philip M | Suggestions for Improvement | Dividing larger tasks into smaller, more manageable units of work would almost certainly increase visibility into the progress being made, and thereby mitigate the appearance that issues are simply stuck "In Progress". |
| Matthew B | Suggestions for Improvement | Team members should come to stand-ups with three things prepared: 1) What they've done since last stand-up; 2) What they're going to do in the next stand-up; 3) What's in their way that the PM needs to solve. Technical discussions about how to implement should be done outside the stand-ups. |
Bugs
Future
Tickets
