topic: Version Control & Scrum using Trello & Github
Scrum roles
- Team Member
Developers, designers, and anyone who’s doing that actual production of work. Responsible for working with the Product Owner to break down tasks & reach completion on different ticket items.
- Scrum Master
The facilitator of the scrum process. If this person is doing their job right, the team becomes independent over time.
- Product Owner
The stakeholder for the product. This person is in charge of deciding what the MVP, and different versions of the product look like. They are also responsible for ensuring the backlog is in correct order.
Scrum Meetings
Planning
- When:
At the beginning of the sprint
- What:
The team commits to a set of tickets for the sprint that they think they can complete.
- Why:
Gives a goal to work towards, ensures that there is a select pool of tickets that the team can then have the freedom to choose as they please.
Storytime
- When:
As needed. 2-3+ sprint’s worth of tickets should be in the backlog at all times.
- What:
The team hashes out different story point from the product manager, converting them into tickets that are an appropriate size with unambiguous requirements.
- Why:
So every ticket is clear on what needs to be accomplished.
Review
- When:
At the end of every sprint
- What:
Team demos all work done for an audience including, but not limited to, stakeholders & team members
- Why:
It’s not only nice to show off work, but it ensures that everything is actually working in harmony.
Retro
- When:
After the end of every sprint
- What:
The team, with the intention of improving the scrum process, covers the following issues together
What went well
What went poorly
What can be done to improve
- Why:
The scrum process should be adaptable to the organization’s needs. This also allows all members of the team to participate and own the process.
Standup
- When:
Every day
- What:
Team answers following questions in order - What did I do to advance the team’s goals in the sprint yesterday? - What is impeding me from working on the team’s goals for this sprint?
All other discussions are tabled for smaller groups afterwards
- Why:
Helps to adapt to problems that come up, and to initiate conversation about different topics.
General issue board procedure
Every time you move a ticket from one column to another, you are unassigning yourself. A ticket in the done column is reassigned to the person who did the development work on it.
Comment on the tickets as a form of taking notes & passing on explanations from one person to another.
Attach all resources to the ticket whether they are points of reference, design documents, etc.
Name the tickets so there is no confusion as to what is being accomplished.
Add every requirement to the checklist, and be specific. Check off requirements as you finish work on them in development.
Backlog
Items in the backlog represent the conceived work for the team over the next 2-3+ sprints.
Before items are able to be moved into the “To Do” column, they need to be looked over by the team during the “Storytime” meeting to make sure that the objectives are clear.
Various labeling/measuring can take place on these tickets, like adding the feature they’re associated with, the estimated work hours to complete the feature, and more.
To Do
Tickets in to-do are in the queue for the team’s current sprint.
The team commits to completing a given amount of tickets in the coming sprint during the “Planning” meeting.
Developing
Tickets moved to developing are being actively worked on by the person assigned to them.
Git Action
Before any coding occurs, pull down the latest version from “origin/main”. Then, after coding is finished, create a new branch with a name corresponding to your ticket. Commit, push to origin, and create a pull request in Github.
Code Review
Tickets in code review are having their associated code (or design) reviewed. A team member will look at the pull request on Github and see that the code is well formed, doesn’t have obvious bugs, and accomplishes what it set out to do. If necessary, changes are suggested, and the ticket is sent back to development.
Git Action
If the code passes review, the pull request is approved and the branch is merged into main.
Quality Assurance
Tickets in quality assurance are being checked to make sure the user experiences what the ticket was set out to accomplish. If there’s bugs or missing functionality, send it back to development.
Git Action
Pull the merge commit from origin/master for testing.
Done
Tickets here are done.