Software engineering project kickoff
- 1 Overview
- 2 Assign roles
- 3 Set up Slack channels
- 4 Configure GitHub repository
- 5 Prepare to Git to work
- 6 Do a daily standup
- 7 Create the initial product backlog
- 8 Plan sprint 0
- 9 What links here
We will do an in-class workshop to complete the necessary setup and kick-off for each team's project. At the end of this workshop, every individual and group will have the tools setup to allow them to collaborate on team projects.
Each team will vote, using whatever voting system they prefer, on which two members will fill the initial roles of Scrum Master and Product Owner.
- all team members, including Scrum Master and Product Owner, are also Developers in this course
- these roles must shift every Sprint, so all team members will fill each role at least once.
- each team must announce which team members are Scrum Master and Product Owner at the start of each Sprint
Set up Slack channels
Slack is each team's primary communication tool. Each member's communications and contributions within Slack are tracked and used towards grading. Communications within private channels are not visible to the Professor and therefore will not be considered when grading.
Each team must have at least two Slack channels where the professor, graders and tutors are also invited to be members:
- a private channel for general team communication
- a private channel for documenting daily standups
- individual participation in these and other channels may be used towards each member's grade
These channel names must be short and consistent. For example, if a team is named 'octopus', their channels might be called:
Donut friends channel
A robot named @donut has been added to Slack. Every week, this robot will automatically invite a few members of the #general channel to meet up for donuts and coffee.
- do this if you are open to meeting other people in the class outside of your group
- go out for donuts and coffee (or for whatever other meeting venue you prefer) when invited to do so, if you wish
- share selfies of your donut dates in the #donut-friends channel
Configure GitHub repository
GitHub is each team's primary resource for version control, project planning, issue tracking, and project documentation. Each member's contributions within GitHub are tracked and used towards grading.
Each team member must request the Professor to add them as a member of their respective GitHub team.
GitHub repositories have been created for each team and are in the control of the team
- each team must collaboratively draft a CONTRIBUTING.md document that includes the recommended elements
- each team must post their Project Requirements document in Markdown format in a file named REQUIREMENTS.md
- each team must collaboratively commit a README.md file to that outlines details of the project that includes links to each of the above Markdown files, in addition to any other useful links.
Each repository must have a .gitignore file that informs git not to track platform code, 3rd party library code, and other common development artifacts that are not your own code. Also do not track files that contain sensitive information, such as usernames/passwords to a database, or files containing users' personal information.
GitHub Issue labels
Each team must create the recommended set of labels for using GitHub's issue tracker for Scrum.
GitHub Issue milestones
Each team must create the recommended set of Milestones to represent each Sprint within GitHub's Issue tracker:
Prepare to Git to work
Each team member must clone their team's GitHub repository onto their own local machine.
Do a daily standup
- Each team must do their first Daily Standup and document it as indicated.
- Each team must set a fixed weekly schedule for subsequent Standups and include this schedule in their team norms included in the CONTRIBUTING.md document in their repository.
Create the initial product backlog
Each team must produce an initial product backlog of user stories based on their understanding of the project requirements so far.
- each item in the product backlog must be added as an Issue to GitHub's Issue tracker
- follow the recommended workflow for adding issues to GitHub's issue tracker
- make sure all user stories in the product backlog have appropriate labels attached to them: user stories have the 'user story' label, spikes have the "spike" label, other types of tasks have the 'tasks' label, etc.
Plan sprint 0
Creating the Sprint Backlog
Each team will hold a sprint planning session to decide which user stories from the Product Backlog to include in Sprint 0's Backlog. The team must follow the established procedure for holding sprint planning sessions.
Each sprint backlog user story must...
- have acceptance criteria included in it as a checklist be assigned the 'Sprint 0' milestone in GitHub's Issue tracker
- have an estimation of work added to it following either of the Planning Poker or tee-shirt sizing work estimation processes
- be assigned the 'Sprint 0' milestone
Breaking user stories into tasks
Once user stories have been added to the Sprint Backlog, the team must then create the individual Tasks that are necessary to implement each the User Story. Tasks are the smallest unit of work, and should typically be doable by one person in one day
Tasks are those things that must be done to complete the implementation of the user story
- these include tasks for each of the things that are necessary according to your team's definition of done
Each task must...
- be made its own Issue in GitHub's Issue tracker
- be assigned the 'Sprint 0' milestone
- be labeled with the 'task' label to differentiate it within GitHub's Issue tracker from 'user story' Issues
- include in its initial description the Issue number of the User Story from which it was derived
- include the number sign, e.g. "This task is part of User Story #4"
Spiking the backlog
This initial product backlog must include 'spikes' for investigating which technologies to use for the project as well as setting up each team member's local development environment.
- These spikes are highest priority and must be completed as soon as possible during Sprint 0
- Spikes must be given the 'spike' label and the 'Sprint 0' milestone in GitHub's issue tracker
Planning poker cards
Each team must agree on a way of estimating work. This can be any of the work estimation methods that we have discussed.
If a team chooses to go with the Planning Poker estimation method, the team must agree upon a deck of cards that they like and will use for work estimation
- it's ok to design your own cards if you have visually or conceptually creative team members
- it is not ok to use Planning Poker software in place of physical cards - doing so goes against the raison d'être of Scrum
- create a Spike for this task in GitHub's Issue tracker, by creating an Issue with the labels, 'spike' and the milestone 'Sprint 0'
- assign this GitHub issue to one of the team members
Setting up the task board
Each team will maintain a shared Task Board for each Sprint using GitHub's Project Board functionality in the recommended fashion. These boards are available under the 'Projects' tab in GitHub - you will have to set up the Sprint 0 task board in recommended fashion.
- Add all User Stories for Sprint 0 to the "Sprint Backlog (User Stories)" column
- Add all Tasks for Sprint 0 to the "To Do (Tasks)" column
Once you start working on tasks, you will move them to the other columns depending on their status.