| Page properties | ||||
|---|---|---|---|---|
|
Retrospective on Kurator Sprint-8 (first cut at proof of concept web application executing a workflow).
| Panel | ||||
|---|---|---|---|---|
| ||||
What did we do well? |
- Got the trivial web UI demos up to show off in the Tuesday meeting at the two week point.
- Having a sprint listing specific issues highlighted work going on but not described in the sprint, which helps us ask if all the work going on is helping us move forward.
| Panel | ||||
|---|---|---|---|---|
| ||||
What should we have done better? |
- Finish up closer to the two week schedule.
- Do we have too many/too broad issues in the sprints? Smaller, bite-sized issues? Perhaps break up larger backlog items into these smaller chunks when starting a new sprint?
- Including everyone's work as issues in the sprint. Time went into learning Docker, dockerizing Kurator-Akka and the web app, and figuring out how to run the web app from the cloud in a way that makes it accessible on the internet, but these activities were not reflected in the sprint.
- Connection of each issue in a sprint to a single overarching theme or user story (which may not be fully achieved) for that particular sprint. Even if it seems at first a bit of a stretch, work on one issue can inform work on others. For example, the light-weight (non-Java) web app work could be seen as a way of ensuring that the Play-based web app can become more loosely coupled to the workflow execution framework. (Currently, Java in the web app calls a Java API in the workflow framework. Should we consider a microservice architecture for running workflows that either the Play app can call, or a Python app, or from any other language?)