Project Kickoff (within an Agile Software Development Course)

Setting appropriate expectations

  1. Ready, Set, Go!
  2. Division of Labor
  3. Discord
  4. GitHub
  5. Product Backlog
  6. Planning Poker
  7. Sprint Backlogs
  8. Task Boards
  9. Git
  10. Daily Standups
  11. Conclusions

Ready, Set, Go!


Teams are know working on their projects. Let’s make sure your workflow and expectations are in order.


Work is divided into increments:


Division of Labor

Wise Use of Human Resources



Each team must have two private channels set up in Discord, e.g.:

Key stakeholders - professor and any course assistants, tutors, and graders - must be invited.


Each team is a member of the larger course organization.

All teams are using the same general technologies and facing the same problems.

Communicate with other teams via Discord. Help each other. Take initiative.



All team members have access to their project’s GitHub repository.

All repositories must include:


Each repository must include a file named .gitignore in the root directory that instructs git to not track certain files and directories.

This file must instruct git to ignore (i.e. not track):

Here is an example general-purpose .gitignore file.

Product Backlog

User Stories

Before work on a project can begin, it must have an initial Product Backlog - a set of user requirements for the project written in User Story form.


Every GitHub repository has an Issues tab where User Stories in the Product Backlog should be written and stored.

GitHub user story issues


Create an Issue for each User Story in the Product Backlog and assign it the user story label to differentiate it from other types of Issues.

Issue Numbers

Once created, each Issue in GitHub is automatically assigned a unique Issue number.

You will use these numbers:

GitHub issue numbers

Issue Templates

Your use of GitHub’s Issues feature must also make use of GitHub Issue Templates:

  1. Download a set of Issue Template Markdown files.
  2. Place these example Markdown files into a directory in your repository named .github/ISSUE_TEMPLATE/.
  3. Push them to the GitHub central repository.
  4. Now every time you create a new User Story, Task, or Spike, GitHub will offer for you to use one these as a starter template.

Planning Poker

Work Estimation

At the start of each Sprint, team members discuss each User Story they are considering including in the new Sprint.

The group will often assign each User Story an estimated level of effort using Planning Poker or some other agreed-upon estimation scheme.


In planning poker, every member of the team must print a set of Fibonacci-based planning poker cards.

Planning poker cards

Sprint Backlogs

Selecting User Stories

Those User Stories selected for the current Sprint are added to the Sprint Backlog.

In addition to the basic requirements for User Stories in the Product Backlog, User Stories in the Sprint Backlog must be assigned:

GitHub issue milestones


Each User Story selected for the current Sprint is immediately broken up into Tasks.

A Task is a unit of work that would ideally take one developer one day.

Task Requirements

GitHub issue tasks


Any work to be done that does not relate directly to a user requirement is documented as a Spike.

In GitHub, spikes are treated like Tasks in all respects except that they are labeled “spike”, not “task”.

Spike Requirements

GitHub issue spikes

Proper Attribution

If the nature of the work requires a particular Task or Spike to be done independently by each developer, it must be split into separate Tasks or Spikes with each assigned to a single team member.

For example:

Task Boards


Each GitHub repository has a Projects tab, where Task Boards can be linked.

Make one Task Board for each Sprint. If your team were named Octapus, name your task boards:


Each Task Board must have the following columns:

GitHub task board columns

Starting State

At the start of each Sprint, the current Task Board in GitHub must contain:

Changing State

The state of the Task Board must be kept up-to-date at all times.

Missing Work

Your performance evaluation/grade depends upon you accurately listing all work you are doing on the Task Board at all times.

If you are doing work whose existence or status is not accurately reflected on the Task Board, you are not doing Agile Development and you will not receive credit for it.


Matching Credentials

The git username and email you use on your local development machine must match exactly your GitHub account login name and email.

git config --global "monalisa"
git config --global

Matching Credentials (continued once more)

Once you’ve made a few commits and pushes via git and tried opening and merging a Pull Request or two on GitHub, take a look at your git logs to verify that your usernames are consistently the same.

  1. Check that your usernames match: run git config to see your git username on your local machine - this is your git username. Make sure it is exactly the same as your login name on GitHub.
  2. Look at your git logs: run git log. Hit the space bar to scroll through the logs and hit q to quit when you’re done. Check your username as it shows up in the logs… is it always correct for every log entry and does it match what you see in your grading emails? If so, you’re done. If not, continue…
  3. If your usernames don’t match, then run this: git config --global "monalisa", where monalisa is replaced with your GitHub login name. Now your usernames match!

Turn off rebasing

git has two ways it can handle pull events, where changes from a remote repository are downloaded and integrated into the local repository: merge and rebase. We want to use merge because this maintains the full history of the project, whereas rebase changes the history to make it simpler and you thus may not receive credit for your full contribution to a project.

To turn off rebasing and use regular merging, you must run this command:

git config --global pull.rebase false

Read more about rebase vs. merge if interested - note the last section of the document.

Turn off rebasing (continued)

When merging pull requests on GitHub, you must always use the “Create a merge commit” option, never the “Rebase and merge” option, for the same reason.

GitHub merge options


Each team member must clone their team’s remote GitHub repository to their development machine.




git checkout -b user-story/13/task/9/implement-user-login
git checkout -b spike/27/learn-react-js

Peer Review

The developer who makes changes must never be the one to merge their own branch into the trunk.

  1. The developer making changes must push their completed branch to GitHub and then issue a Pull request to the main branch
  2. The same developer must, of course, update the position of the relevant Task that this branch implements on the Task Board.
  3. A second developer must review the changes in the pull request, approve them if good, and merge them into main.

Both developers are responsible if poor quality code is integrated into the main branch.

Daily Standups


Every morning, the entire development team gets together. Everyone quickly and honestly answers three questions:

  1. What did you do yesterday (or since last meeting)?
  2. What are you doing today (or until next meeting)?
  3. Do you have any problems that are blocking your progress?


The current Scrum Master must document each team member’s answers to the three questions and post them to their team’s Discord standups channel.

Include the Discored handle of each member and their responses and whether they were in-person or remote, e.g.

@foo_barstein (in-person, synchronous):
- did: Completed 95% unit testing code coverage of codebase
- doing: Implementing the Observer design pattern
- blocking: Nothing

Include notes for all team members in a single post.


All teams must include in their Team Norms that team members agree to answer the Daily Standup three questions honestly and fully.

It is in all team members’ interests to report blocking problems or underperforming team members to their “managers” immediately.

If a team member is doing the same work for several Standups in a row, yet is not reporting any blocking problems, this is a sign of a big problem for the entire team.


Thank you. Bye.