Home
Our team has a particular way of using GitHub's provided tools, terminology, and sections that may be different from the mainstream and may not be obvious to first-time users of GitHub. This page describes such differences and the evidence you'll see in this repository:
Our team is using an Agile Software Development methodology called Scrum. We'll be following the full definition outlined on scrum.org:
The Scrum Framework (Borrowed from scrum.org)
The Agile (Increment) Framework (Borrowed from devcom.com)
You'll see us record the Scrum ceremonies or meetings that drive our work:
Daily Scrums (Stand-up Meetings). We host our daily Scrums twice a week or so, where we discuss the work we've each done since the last Scrum, any bugs people may have discovered in the meantime, and the future outlook of the Sprint we're currently on.
Meeting minutes are recorded under the Meeting Minutes section of the Wiki.
Sprints. We split our work into two or three week time boxes that we'll be using to complete a set amount of work, such as creating software design documentation or a few features of the software (like a set of related windows or forms, or even back-end development like an email system).
Sprint Kanban Boards are found under the Projects tab above.
Sprint Planning. We'll usually plan our Sprints before we start them, on the day of or day before we start one. This involves us pulling in issues related to our Sprint goal into the related Kanban Board and starting the sprint.
There are no Wiki pages for Sprint Planning, we use the Projects boards to record Sprints.
Sprint Review and Retrospective. At the end of each Sprint we will host a meeting to demonstrate what was completed in the Sprint - the Sprint Review. Afterwards, we discuss and write down how well we believe the Sprint worked for us - the Sprint Retrospective: the planning, the amount of work done, the ease of work completed, etc. to better plan the next Sprint.
Sprint Retrospective notes are recorded under the Project process-related section of the Wiki.
Backlog Refinement. During each Sprint we will host meetings to create our Product Backlog; particularly, we'll be adding issues/tasks to the Issues tab above that detail future work pulled from our Deliverables, Requirements gathering-related, Software design-related, and Technological discussion Wiki pages.
There are no Wiki pages specifically for Backlog Refinement, we use Issues to record the Backlog.
Our team member responsibilities reflect the different positions outlined on scrum.org:
Scrum Master. The current Scrum Master is Kelly Holtzman. The Scrum Master is responsible for coordinating Scrum ceremonies and tools (think the Sprints and the Projects/Milestones/Issues pages) to both follow the Scrum Agile methodology and advance the team forward to project delivery. Further responsibilities include helping the development team to construct and adhere to a definition of "done", and assisting the Product Owner with prioritizing work completion and forecasting project process.
Product Owner. The current Product Owner is Sana Khan. The Product Owner is responsible for coordinating the clients needs against the Product Backlog, to ensure the team is developing solutions that address the clients needs. The Product Owner shall assist in the development team's understanding of items in the Product Backlog, and clear up misinformation where needed. Further responsibilities include prioritizing work in the Backlog and for Sprints to best achieve the clients needs.
Development Team. All members of the project participate as developers. The development team is responsible for addressing items in the Product Backlog such that each Sprint completion pushes out a potentially releasable, "done" increment of the project.
Our Wiki is meant to document project process in a number of ways:
- We'll record meeting minutes for both Scrum and ad-hoc meetings (Meeting Minutes),
- Requirements gathered from our client: both raw and organized (Client-given raw information and Requirements gathering-related),
- High-level discussion of tools we're considering for use and/or currently using for tasks such as continuous integration, automated building, and code formatting (Technological Discussion), some technological discussion is done in the comments of the related investigation task instead of the Wiki
- Scrum ceremonies, such as the Sprint Retrospective (Project process-related),
- Project Specifications, Functional Requirements, Architectural Design, etc. and their revisions (Software design-related),
- and Deliverables designated from URCourses (Deliverables)
Links to pages in section-order can be found in the sidebar to the left.
Our team is using the Projects tab above to create Kanban Boards for each Sprint. Each Project is a Sprint or another time-boxed increment of work (such as a "side-Sprint" to update documentation alongside the current Sprint).
Our team is using Milestones to group similar issues in the Issues tab above.
- Milestones may or may not have a due date, and that due date may or may not correspond with Sprint start/end dates.
- An entire milestone may or may not be included in a single Sprint.
- A milestone may stretch the whole project (such as a milestone to group issues that updated tools used for development - updates occur throughout development and are not directly related to deliverable increments).
Ergo, our milestones are not directly correlated with Sprints despite the inherent ability to do so.
If the reader is familiar with User Story Mapping, the breakdown of milestones to issues is alike that of epics to stories.