Home

Suggestions on how to use the scrum base repository

Project Workflow

How-to select an appropriate issue template.

Look at descriptions of issue types and follow instructions on templates. The templates should have standards for how things are written.

Internal:

• Epic - Large piece of work that encompasses many issues and should be broken down
• Story - functionality request expressed from the perspective of the use
• Hotfix - Urgent fix that need immediate attention
• Documentation - Task related to the documentation of the project

External and internal:

• Feature request - Submit a proposal/request for a new feature
• Question - Ask a question
• Bug - Submit a bug report to help us improve

How-to sprint planning:

Figure out how much time you have and what issues you can fit in the time frame of you project. Make sure that user stories are groomed and ready to be processed.

How-to groom user stories:

Should happen before stories are committed to a sprint. The activities that happens on this meeting is: Discuss how to go about solving the problems in the issues and access if it's too large and need to broken down further. Estimate the time it takes to finish the issues using e.g. Poker planning game Poker planning tool

How-to retrospectives:

Do activities, scheduled by facilitator. Look to this site for inspiration or google other resources. -> https://luis-goncalves.com/agile-retrospectives-ideas-exercises/ Should include something that examines “how we work” and other processes. Start-Stop-Continue etc. Reach consensus on changes and write changes in change log somewhere. So you'll remember why the change was made should someone want to change it back later they can view some reasons for why not to, and make the judgement if it's worth it.

Workflow from Kanban Board:

Working from right to left on the board, to avoid congestion issues as reviews will eventually pile up till it’s an unhandleable mess.

How-to start working on an issue:

Open a new branch with issue type you’re trying to solve and paste in issue number in the end. As such: bug-#5. This will automatically move the issue to in-progress on the board. Apply commits with the changes, open a pull request, add issue name as title. Fill in the required information. Reference issue that is being handled. Change will be committed once review, has been done.

How to commit and push

Generally agree upon a writing style within your team. And make sure to commit and push often, you can always amend your commit descriptions

Here some general guidelines for writing commits adapted from gits documentation. And directly taken from: Source

A properly formed git commit subject line should always be able to complete the following sentence

If applied, this commit will <your subject line here>

Rules for a great git commit message style

• Separate subject from body with a blank line
• Do not end the subject line with a period
• Capitalize the subject line and each paragraph
• Use the imperative mood in the subject line
• Wrap lines at 72 characters
• Use the body to explain what and why you have done something. In most cases, you can leave out details about how a change has been made.

Information in commit messages

• Describe why a change is being made.
• How does it address the issue?
• What effects does the patch have?
• Do not assume the reviewer understands what the original problem was.
• Do not assume the code is self-evident/self-documenting.
• Read the commit message to see if it hints at improved code structure.
• The first commit line is the most important.
• Describe any limitations of the current code.
• Do not include patch set-specific comments.

Details for each point and good commit message examples can be found on https://wiki.openstack.org/wiki/GitCommitMessages#Information_in_commit_messages