A project is divided into sprints of ten days each. A sprint is a two-week mini-project. 

No content

Did you ever think: We never have time to re-pay technical debt. Half-baked features are painful. Friday deployments are stressful. 

aka: Never deploy on a Friday! Sprints start on a Wednesday and ends on a Tuesday. 

This is where the development happens. Building features for the first 8 days. 

No features are started in this period. Feature freeze: Fixing bugs for the last 2 days. 

This coincides with the next sprint. Deployment on the next morning after the sprint. 

Sprints: A sprint is a two-week mini-project. Start on a Wednesday. Never deploy on a Friday. Feature freeze on the last 2 days to iron out bugs. Deploy after the sprint, the morning after. 

A project is divided into sprints of ten days each. A sprint plan is a to-do list for the next 2 weeks. 

Did you ever think: There's no plan except to "just build things." We never know what we're working towards. 

Just Markdown or plain text can be fine. Sprint plans are very simple. sprint-plan.txt • • • Article editing - George • Wysiwyg editor • Image uploading Article view improvements - Paul • Responsive view • Print view Comment moderation - Ringo • Approve/reject comments 

In Trello, it can be a Trello list. Sprint tasks should be in your task tracker. Trello • • • 

Talk about the previous sprint and the next sprint. Schedule a meeting every sprint start. Retrospective of the previous sprint — Planning of the current sprint 

Sprint planning: Create a Sprint plan. Fill up your task tracker for the current sprint. Schedule a retro + planning meeting every sprint start. 

This version number consists of two numbers. Label your sprints using version-like sprint numbers. 1.2 

Did you ever think: "What sprint are we on, again?" "Did you deploy something last night?" "Who did the last deployment?" 

The first number is the milestone, the second the sprint. The numbers tell you what milestone and sprint you're in. 0 . 1 Milestone Sprint 

Each Milestone is a big goal to be achieved in 2 to 6 months. Plan your project in milestones, which are divided into sprints. 0.1 0.2 0.3 0.4 First sprint ever Posting articles Searching, commenting (aka 1.0) Polish and first public release 1.1 1.2 1.3 1.4 Slight redesign Groundwork for ads Connect to social media accounts (aka 2.0) Polish and re-launch Milestone 0 — Release MVP Milestone 1 — Scaling to 10k users 2 weeks 2 weeks 2 weeks 2 weeks 2 weeks 2 weeks 2 weeks 2 weeks 

These are based on the sprint numbers. Every production deploy should have a version number. v 1 . 2 . 0 Sprint number Deploy number in this sprint 

At the end of sprint 1.3, do a v1.3.0 production deploy. Sprint 1.3 is working to release v1.3.0. Start of sprint 1.3 May 5 (day 1) Release of v1.3.0 and start of sprint 1.4 May 20 (day 10+1) Release of v1.3.1 to hotfix some bugs May 21 (day 10+2) 

This number is based off the sprint number. Every production deploy should have a version number. v1.2.0 

These 3 numbers are roughly in semver format. Version numbers are based on the sprint number. v 1 . 2 . 0 Sprint number Deploy number in this sprint 

This creates a Git tag. Git tags are made using GitHub releases. 

GitHub releases does this under-the-hood. They're the same as tagging it using the Git CLI. ~$ git tag v1.2.0 ~$ git push origin --tags Terminal • • • 

Version numbers: Name your sprints with a sprint number (eg, 0.1). Group your sprints into 2-6 month Milestones. Every production deploy has a version number. (eg, v0.1.0). Use Git tags for tagging version numbers. 

Deployment should be taken care by CI. Deployment workflow 

Did you ever think: "How do you deploy again?" "Who has SSH keys?" "Do I need to install Ansible/Capistrano/Fabric/etc?" 

This will deploy production when merged! Prepare a develop → master pull request. 

Assuming, of course, you set up auto-deployments! Merge it. CI will auto deploy when master is updated. 

Give the deployment a version number. Tag and write release notes using GitHub releases. 

Deployment: 1. Create and merge a master pull request. 2. Let your CI automate deployment of master. 3. Create a GitHub release to tag your deployment. 

This should be as automated as possible. Writing release notes Rn 

Did you ever think: QA needs to check the latest changes. QA has no idea what they are. "The Client is asking what's changed and I don't know what to say." "I was on vacation, what did I miss?" 

Terminal • • • ~$ git fetch ~$ git log origin/master...origin/develop \ --first-parent \ --oneline Inspecting differences between two branches This gets you one all PR's merged. bec8d46 Merge pull request #819 from x/feature c9ca921 Merge pull request #818 from x/feature 1ba92d4 Merge pull request #814 from x/feature 92b4cd0 Merge pull request #816 from x/feature 00f2bde Merge pull request #802 from x/feature de821a4 Merge pull request #798 from x/feature bec8d46 Merge pull request #794 from x/feature c9c14aa Merge pull request #788 from x/feature bec8d46 Merge pull request #784 from x/feature c9ca921 Merge pull request #785 from x/feature 1ba92d4 Merge pull request #786 from x/feature 92b4cd0 Merge pull request #778 from x/feature 

Terminal • • • ~$ git fetch ~$ git log origin/master...origin/develop \ --first-parent \ --oneline Inspecting differences between two branches rev1...rev2 Include commits reachable from rev2, but not rev1 --first-parent Follow only merge commits --oneline Condense display of Git log 

Terminal • • • ~$ git fetch ~$ git prlog origin/master...origin/develop \ | sort \ | pbcopy Automating this using git-prlog See: http://github.com/rstacruz/git-prlog - Admin: allow login from iPad #814 - Admin: fix notification bug #819 - Admin: list posts alphabetically #815 - Comments: fix formatting #809 - Comments: fix Markdown issue #810 - Comments: allow commenting on posts #811 - Posting: allow uploading images #849 - Posting: use S3 for uploads #850 - Posting: prevent trackback spam #852 - Posting: fix mobile responsiveness #850 

Terminal • • • ~$ git fetch ~$ git prlog origin/master...origin/develop \ | sort \ | pbcopy Automating this using git-prlog See: http://github.com/rstacruz/git-prlog git-prlog See: github.com/rstacruz/git-prlog | sort Sort lines alphabetically | pbcopy Copy to clipboard (OSX) 

Release notes: Write release notes. Use Git to help you write release notes. 

To sum it up: Organize your efforts into milestones and sprints. Enforce a feature freeze period every sprint. Use version numbers and Git tags. Let Continuous Integration do the deployment for you. Write release notes to keep everyone informed.