Sprint Retrospective

Software Design and Architecture (+ API Design)

• Able to provide functionality, that is able to show all of the services that we offer such as creating, rendering and sending

• researched into a number of different platforms

Data Modelling

• Broke the application into smaller processes such as creating an account, creating invoice and sending the invoice.

• show relationship between the different layers and flow of information

• Since sprint 2 we have stuck to a consistent DB structure, which has helped in planning our design and constructing a solution

• Wide range of actions and use cases. Can be quite complicated to model some of the more complex and larger use cases

• Able to model some of the more complex use cases, such as creating an account, creating invoice, rendering in and sending it as on sequence diagram to show the flow between the different APIs instead of them as seperate diagrams

Software Quality / Development of the Service

Deployment

Project Management + Communication

• Consistent updates on progress from team

• Good use of sprint planning - to delegate tasks

• Consistent meetings - when needed which included free workspace times → + group programming

• Good use of meeting times, to discuss issues and any group related tasks

• Improvement on giving prior notice if unable to make meetings or work on things

• creating tickets for any needed documentation, so that it is clear who is working on what and if they have been completed

• better use of stand ups. Often forgotten on day they were supposed to be done.

• Members were able to join at the start of the meeting time

• reminders to complete stand ups on day they are due

• when sprint planning, adding tickets for any documentation that is required

• having meeting times where members are awake and able to join at the agreed time. Only suggesting times that you know you'll be able to wake up for, so that there is no wasted time.