Stand-Up
What have you done, what are you doing, what are you yet to do?
Moad, Adam
(insert extra notes here)
James, Myoran
(insert extra notes here)
Luke
Agenda
– Discussion around VS Code debug
– Start planning sprints
– Breakdown of user stories into tasks
– Set up Trello board
– Development of burn-down chart
– Start first sprint
Trello Workflow Board
Board Template:
Populated Board:
Each user story has been broken down into tasks. These tasks can be found in the ‘Comments’ of the user story card, and will be displayed as checklists.
Story Size
In this meeting we addressed some assumptions made Story Size Scale. Chief amongst them is the weekly time commitment that developers had allotted for this project. Due to the developers having a full course load of assignments and study, the total story size that developers can tackle in the sprint will have to be adjusted.
We will revisit this concept in the Sprint 1 retrospective to tweak the assumptions.
Burndown Chart
Sprint 1 Burndown Predictions
This was another planning session held by the group.
It is a follow up from the workshop on Friday as the group didn’t complete all the appropriate work by the end of the workshop. This was due to difficulty presented when identifying tasks for the backlog. There is a whole wealth of issues and finding appropriate ones requires a lot of time and research.
Story Sizing/Scaling
Each story the group identified had to be sized. Sizing varies from team to team, in all manner of workplaces.
The group settled on a sizing system that the SCRUM Master, Luke had used over summer. It was a simple way of identifying length of stories so that the group is able to start formulating timescale and complexity of each task
When sizing stories it’s very important to take into account unknowns and potential complexity of the task. Accurately estimating work can be difficult, especially when working with an unfamiliar code base, but using logic and reasoning the group is able to make a reasonable estimation.
The use of story points also aids with the creation of burndown charts.
The actual story point methodology is based off working days (Mon-Fri) and is as follows:
(1) – A half days work.
(2) – A full days work.
(3) – 1 and a half, to 2 days work.
(5) – 3 days work.
(7) – 3 and a half, to 4 days work.
(10) – 5 days work.
(12) – 6 to 7 days work.
It was agreed among the group that should a task be 12 points then we should consider breaking that task down into multiple tasks in order to facilitate workflow.
Backlog
Tasks have now been sized and put in order of preference. See below image.
Click here: Backlog
Sprint(s) and Burndown charts
Duration – 2 Weeks
To be planned at the next meeting.
Next Meeting
– Identify preferences for tasks, who wants to undertake which task and with who.
– Who’s happy to work by themselves, who wants to work in pairs.
This was the first workshop that signifies the official start of our open source group project.
Link to the worksheet: Workshop 6 – Beginning your SCRUM
There was a multitude of things to do, mainly:
– Setting up a GitHub repo/branch
– Setting up this very blog
– Identification of features and bug fixes within the project selected
– User Stories creation
– Product backlog consideration
– Sprint backlog
– Burndown charts
Firstly, a GitHub repo/branch wasn’t created as the group still aren’t 100% sure that VS Code is definitely the project they want to undertake.
The blog was set up successfully and posts completed up-to-date.
User stories and a product backlog was considered. They were not formulated into an organised list and priority set as we are yet to be 100% committed to the project we are looking into.
See the list created here: Potential Tasks – 11-11-16
Due to the nature of the task list, a sprint backlog is yet to be created, as are burndown charts.
The group are meeting again on Monday 14th November, 2pm to further discuss and formulate their ideas. These tasks should be done by then and as such, the group will remain on track.
On Tuesday 8th November the group held an initial planning meeting.
This was to get our heads around the work we’ll have to do on the lead up to the deadline. Below is a simple, brief Gantt chart that was produced at the meeting in order to help the team start formulating a workflow schedule (click to enlarge).
Discussions were had regarding the SCRUM methodology, familiarisation with how the group would work and detailed discussion/analysis of what a sprint will actually consist of.
The team also reached out to one of the senior project managers of VS Code for suggestions on which issues/features require implementation/resolving. Below is the string of emails exchanged (click to enlarge).
Another reason for the meeting was to start discussing team roles within a SCRUM methodology. The team took into account all previous experience and technical ability when selecting these roles.
The team eventually settled on:
Scrum Master: Luke Exton (12454556)
Tech Lead: Moad Zardab (14467071)
Developer: Adam Plunkett (14516319)
Developer: James Middleton (13389226)
Developer: Myoran Mathusuthan (14464458)
The possibility of a plan ‘B’ was also considered – i.e. ‘What if VS Code isn’t suitable for our project?’. Although, this was set to be discussed further at our next meeting on Friday 11th November, 1pm – 3pm. It was agreed we would all look into alternative projects just in case.