Create guidance documentation for starting first sprint

[stevebrownlee]

Starting Your First Sprint

Setup

Create Project Board

1. Go to the team's Github repository page.
2. Click on the Projects tab at the top.
3. At the top of this view, you will see a green Link a project button, click on the down arrow on the right of it.
4. Choose New project then click on the green button.
5. Choose Board from the types on the window that appears.
6. Enter in the name of your product in the Project Name input field at the top.
7. Click green Create project at the bottom.
8. Add a Backlog column and move it to be the first column on the left.

Adding Tickets to Backlog

Tell your instructors in your team Slack channel that you are ready for the tickets to be migrated and they will begin that process. Once you are notified that the tickets have been added to your client side repository, you will add them to the Backlog column.

1. Go to your project board.
2. At the bottom of the Backlog column click on the plus sign.
3. Click on the plus sign again.
4. Choose Add item from repository
5. In the window that appears, make sure your team repository is chosen in the dropdown.
6. All tickets that you have created will appear in a list.
7. Choose them all
8. Click the green Add selected items button at the bottom.

Adding Story Points

1. Watch the Planning Poker video to learn about the process of weighing your tickets for Sprint Planning
2. You will be adding story points to the first 15 tickets only.
3. Use the planningpokeronline.com site to start weighing your tickets.
4. When you are done with the first 15 tickets, discuss how many you feel you can complete in the Sprint.
5. Move those to the To Do column

Strategies for Completing Tickets

1. Refer to the Rules of Engagement document to make sure you understand what the Definition of Done is.
2. You should not have more than 2 tickets in the In Progress column at any time that are assigned to a single teammate.
3. When you move a ticket into the In Progress column, you are taking ownership of the entire feature. Start with building the API portion of the feature, then build the client components needed.
4. Once all work on both the API and client is approved, you can consider the coding of the feature done and you can move the ticket to the Done column.

Pull Requests

Creating

Everyone on the team should read the Writing A Great Pull Request Description article before creating any pull requests. When you are ready to create a pull request for your branch follow the guidance in that article.

If any changes any required on a pull request, you do not close the PR. Make the change on the branch, and simply git push the branch again to update the existing PR.

Reviewing

Reviewing code is just as important as writing code.

1. The team should discuss the strategy you want to follow as a team for balancing writing code and reviewing code. Each teammate should have a goal of reviewing as may PRs as they have created.
2. When you are reviewing a teammate's code are are performing two important tasks:
   1. Follow the teammate's testing steps and verify it works as intended.
   2. Review teammate’s code for clarity, following conventions, advice on improvements.
3. Watch the How to Review a Pull Request in GitHub the RIGHT Way video for how professionals review a teammate's PR on Github.

[Valerie-Freeman]

Loved the planning poker video. Maybe some additional instruction would be beneficial in that section about the team reading through each ticket together and that they should discuss the ticket thoroughly together before voting on the story point.

Add a point in the Strategies for Completing Tickets section after the first point that when they made their commitment in for which tickets to pull into the sprint, they are committing to getting those tickets done in this sprint.

Give an example of a PR description in this context using the template provided in the article. Maybe one for Posts or something like that as long as it doesn't "give too much away"