Scrum Using GitHub
As this project is also used as a learning space for ITA groups which are colocated in timezone and space we use Scrum process to deliver some features. This page describes how we manage Scrum over GitHub project.
For each course we create separate board. You can find active project using this query.
This section gives an overview of Scrum process we'd like to use for ITA.
Before team can take anything into work they should understand features and size them in order to support future planning. Team meets with PO on regular basis in order to clarify requirements.
Note: If PO is not present on the grooming then put your questions into issue comments and mark it with req-needed label
Once requirements are clear team can size them. We use Story Points as a measure. As an estimation technique we use Planning poker.
As a team collocated they can use Planning Cards or some online tools like Pointing Poker app
Note: Once team estimates a particular issue they should mark mark issue with appropriate label. Look at labels starting with "points:" points: 0,points: 1,points: 2,points: 3,points: 5,points: 8,points: 13
Use points: ∞ for very big issues which have to be split into smaller ones.
Sprint planning consists of 2 steps:
- Team takes items from Team Backlog according to priority and fills up Sprint backlog until there is enough work.
- Each issue taken into sprint should be split into subtasks describing particular steps to get issue into done state.
Important: It is crucial that whole team participates in task breakdown and each person is comfortable with any task
As 
GitHub does not support sub tasks we need to create separate issue for each sub task and link it to parent.
For each subtask you have to do following things:
- Create issue with label
type: subtask. Name should be descriptive. Also add detailed description so you don't forget what you've decided - Reference subtask from parent issue. (See example Test Issue)
- Put reference to parent issue in subtask description.
Note: As we don't have QA we do manual testing by developers. So each issue in general should have at least 2 subtasks one for implementation and another for testing. Those subtasks should be executed by different team members. But not all items require such subtasks so chose according to the particular case.
All created subtasks are put into To Do column. Consider priority here as well.
Each team member assigns task for themselves and caries them to completion. Once corresponding task is done you should mark its related subtask item as done in parent issue.
Issues in Sprint backlog are closed after Sprint demo/revew.
Team demonstrates completed work to PO. If issue matches DoD it will be closed.
Team gathers to analyze what was good or bad during sprint. During meeting each team member answers 2 questions:
- What was good during sprint?
- What should we improve?
After all team members shared their opinions team analyzes answers for question #2 and tries to come up with a solution on how to fix mentioned issue.
Contains all issues which are planned to be done for ITA group in priority order. PO adds issues here and manages priority. Team estimates items
List of issues team commited to accomplish in given sprint.
List of all subtasks for this particular sprint.
Items which are currently being worked on or onder review.
All done issues