Planning

Minimum Viable Product

From our requirements, we figured out that our main tasks were to:

Send an email with the invoice
Create a communication report
Be able to send to multiple recipients

We decided our MVP was to be able to send an invoice to the recipient via email.

Epics

We made those 3 points outlined above our epics, and mapped them out on our roadmap/gantt chart, having sending an invoice as first on the timeline with communication report and multiple recipients being further down the line. This reflects our priorities and the fact that epics 2 and 3 cannot be completed unless there is significant progress in epic 1.

Issues

After being broken down into epics, tickets were created under each. For example, sending an invoice was broken down into first having a framework for flask, then being able to send an email, and finally sending an email (with subtasks of loading the XML and saving the XML). Subtasks were also used almost like checkboxes - the communication report required readable error messages or success message, and also time sent. These were subtasks that could be “done” under the bigger task.

Priorities

Priority	Reasoning

Priority	Reasoning
Highest	Great amount of urgency with the task and should be completed within the next few days / before the next stand up / meeting. Strict to soft and hard deadlines. Assignee should instantly update team for progress check. If assignee were to need help, other lower priority (e.g. lowest, low, medium and high) should be stopped in order to complete highest, regardless of time or difficulty involved. Each member should provide input on additional insights and feedback on ensuring quality of task.
High	Sense of urgency with the task and is to be completed before the next meeting. Assignee should update progress on tasks through asynchronist / synchronist standups. Strict on any soft deadlines that are created by the team.
Medium	Required to be completed before the iteration is due. Somewhat strict on soft deadlines created by the team.
Low	Highly preferable to be completed before the iteration is due, though not strictly necessary. Somewhat flexible to any soft deadlines that are created by the team. Can possibly rely on any issues, yet does not affect the long term
Lowest	Does not need to be completed before the iteration is due. Very flexible to any soft deadlines that are created by the team. Does NOT rely on any other issues, nor no issues rely on this issue to be completed Can constantly be amended throughout the running of the project

Priorities have been allocated according to the MVP. The task of simply sending the invoice was vital - so those were very high priority with the first of those, setting up flask or sending a simple email the highest priority. Additionally, any tasks that would affect the continuation in completing other tasks were also taken as high priority, such as setting up the Flask or even initially assigning team roles, in order to ensure every member had direction and an understanding of their role in the team. Further tasks were lower priority, such as setting up checking email address that are due .

All other tasks were given a low - high priority, as there was no set specific time or strict deadline by which they needed to be completed ~ and hadn't relied on other tasks also being completed. This allowed for flexibility in terms of soft deadlines that were set.

Dependencies and Prerequisites

Dependencies and prerequisites have been highlighted by using the “blocked/blocking” function on Jira. For example, in https://unswseng.atlassian.net/browse/SE2Y22G21-48 , it is blocked by https://unswseng.atlassian.net/browse/SE2Y22G21-46 . The order in the backlog reflects this - tasks were sequenced logically (for example, there needs to be multiple emails sent before we can make a communication report with multiple deliveries).

Story points

Story points were allocated according to the difficulty, the amount of work needed, and skill required. Tasks such as checking email were simple, doable, and required less skill thus given 1 story point. This is because a similar task was done in COMP1531. Tasks such as sending email with invoice has subtasks, is more time consuming, fiddly and requires skill, thus were given 2 or 3 story points.

https://www.atlassian.com/agile/project-management/estimation

Story Point	Reasoning

Story Point	Reasoning
1	Does not require a high level of knowledge/skill in programming Not dependent on too many things Low effort, less tasks Easily done individually Many resources available to help complete task
2	More skill required More tasks required, more to achieve May need help from other team members
3	Needs higher levels of skill Time consuming Fiddly High chance of requiring assistance from other team members High chance of requiring assistance from tutor Less resources available to help complete

Allocation

Task allocations may not seem equal if we only count the number of tasks, or the number of story points. However, it is equal according to each team member’s capacity - in our previous meetings, we have gauged and noted each team member’s experience and skills. We also took into account what tasks team members preferred to do, if they had a preference. For example, Joshua and Edward have a higher interest in setting up flask and other server related things, and also have the skills for that, thus were allocated those tasks.

Additionally, through previous experiences of understanding Story Point allocation, Epics and understanding priorities, Tay was able to take lead in this role in ensuring all members had an understanding. Through this, there were many of times, where members worked alongside each other in pair work, to offset the workload (as well as provide more insights). This includes co-creating the User Stories, as well as discussing what the team defines as highest to lowest priority, as well as the story points.

Planning for Iteration 2

We are going to do our Sprint Planning on 1 March - in our tutorial, on the first day of the sprint.

SE2Y22G21