Retrospective on Kurator Sprint-8 (first cut at proof of concept web application executing a workflow).
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.
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?)
Have mockups as part of sprints, or planning for sprints, to guide or clarify development of web app, other GUIs.