cheat sheets / project management
Scrum, Markdown & Git Cheat Sheets for Software Teams
Three short, authoritative references for how software teams actually work, plus the parts teams reliably get wrong: what the Scrum Guide does not say, and why Markdown behaves differently in different places.
Running software projects is mostly a few well-understood practices applied consistently. The Scrum Guide is the short official source for the framework most teams claim to use, Markdown is the language your docs and tickets are written in, and Git is how people collaborate without overwriting each other. All three references below are free and authoritative, and all three are short enough to actually read rather than skim.
01 · THE REFERENCES
Process, docs & collaboration
The references behind day-to-day team delivery. The Scrum Guide in particular surprises people with its length: the entire framework is defined in a document you can read over a coffee.
- The Scrum Guide (official) ↗The definitive, free, and surprisingly short rulebook for Scrum — roles, events, and artifacts from its creators.scrumguides.org
- Markdown Cheat Sheet ↗The syntax for every README, ticket, wiki, and doc — headings, lists, tables, and links in one clean reference.markdownguide.org
- Git Cheat Sheet (official PDF) ↗How the team collaborates — branching, merging, and pull-request workflows from GitHub's own reference.education.github.com
02 · SCRUM
Read the guide, because most Scrum is not Scrum
The Scrum Guide defines a deliberately small framework: a set of accountabilities, a set of events, and a set of artifacts, each with a stated purpose. Almost everything people complain about when they complain about Scrum is not in it. Story points are not in it. Two-week sprints specifically are not in it. Neither are burndown charts, a daily meeting where everyone reports status to a manager, or the idea that a Scrum Master assigns work. Reading the actual document is the fastest way to see how much local practice is convention rather than requirement.
The event most commonly misused is the daily meeting. Its stated purpose is for the people doing the work to inspect progress toward the sprint goal and adapt their plan. When it becomes a round of status updates delivered to a manager, it stops serving that purpose and turns into the ritual everyone resents. The retrospective is the one teams skip first under pressure, which is unfortunate, since it is the only event whose job is improving how the team works rather than what it produces.
03 · MARKDOWN
There is no single Markdown
The most common source of Markdown frustration is assuming it is one language. The original specification was loose enough that implementations diverged, and today a document can render differently depending on where it is published. CommonMark exists to pin down the ambiguous cases, and GitHub Flavored Markdown builds on it with additions like tables, task lists, and strikethrough. Those additions are exactly the features most likely to break when you move a document elsewhere.
A few habits keep documents portable. Stick to the widely supported core for anything that might move between systems, and check how tables and nested lists render in the destination rather than assuming. Indentation inside lists is the other frequent problem: many implementations are strict about how far continuation content must be indented, and inconsistent spacing produces a mysteriously broken list.
04 · GIT AS A TEAM SPORT
The habits that make collaboration painless
Most Git pain is social rather than technical. Long-lived branches diverge, and the longer they live the worse the eventual merge, so integrating frequently is the single most effective habit a team can adopt. Small, focused commits with messages explaining why rather than restating what make review faster and make history useful when you are trying to understand a decision two years later.
The rebase-versus-merge argument is less important than a team agreeing on one approach and applying it consistently. What genuinely matters is the rule underneath it: rewriting history that others have already pulled causes real problems, so keep rewriting to your own local or unshared branches. On a shared branch, prefer the operations that add history rather than rewrite it.
Finally, learn the recovery commands before you need them. Git very rarely loses committed work, and knowing that a record of where your branches have pointed exists, and can be used to recover from a bad reset, turns a panic into a two-minute fix.
05 · FAQ
Frequently asked questions
Is the Scrum Guide free?
Yes. It is published free at scrumguides.org by Scrum's creators, and it is short enough to read in one sitting. The Markdown and Git references listed here are free as well.
Does Scrum require story points and two-week sprints?
No. Neither appears in the Scrum Guide. Story points, burndown charts, and a specific sprint length are common conventions that teams add, not requirements of the framework, which is why reading the actual guide is worthwhile.
Why does my Markdown render differently on different sites?
Because there is no single Markdown. Implementations diverged from the original loose specification, so CommonMark exists to pin down ambiguous cases and GitHub Flavored Markdown adds features like tables and task lists on top. Those extensions are the parts most likely to break when a document moves.
Should my team use rebase or merge?
Either works as long as the team agrees and applies it consistently. The rule that actually matters is not rewriting history others have already pulled, so keep rebasing to your own unshared branches and prefer history-adding operations on shared ones.
Do I need Git certification or training to work on a team?
No. A handful of commands covers nearly all day-to-day work: branching, committing, pushing, pulling, and resolving conflicts. Learning the recovery commands early is more valuable than any certificate, because it removes the fear that makes people avoid using Git properly.