Playbook Menu
The BiteSite Playbook
Overview
Culture
Custom Software Values Team Members How we hire How we work Communication MVP
Sales
Customers Customer Role Sales Process Project Types Contracts
Scrum Express
Scrum Express Roles Development Sprint How we use Trello Product Managers Project Leads Designers Developers
Toolkit
Technologies Tools Git Strategy
Business
Invoices and Payment Project Handover

Development Sprint

Scrum Express centers around fixed, predictable chunks of development called Sprints. Our typical development sprint is depicted below.

(The diagram above and descriptions below give a high level overview of how Scrum Express is run. However, it can be tricky to manage this process without a good tool. We use Trello and after reading the high level overview below, be sure to check out How we use Trello to manage Scrum Express.)

Stages

Sprint Planning

Every Sprint starts with a Sprint planning session. This is usually a 15 to 30 minute meeting where the entire team decides what is going to be developed, tested, and delivered within the Sprint. A lot of times this involves simply picking cards from the top of the Product Backlog and putting them into the Sprint.

Aside from the top of the Product Backlog, the team also takes a look at any last minute Incoming Feedback cards that came in that can be slotted in. This usually involves high priority, or urgent cards.

To decide how many cards to put into the Sprint, the team can track a general velocity - the number of points the team generally delivers. For a more detailed breakdown of points, take a look at Estimation Poker.

Once the Sprint is planned, in general the goal is to not touch what is in the Sprint. The creates a predictable week of development, testing, and deployment.

Main Development

After the Sprint has been planned, the developers start taking cards from the Sprint and start their work. They make all the necessary code changes, review each others' code, prepare test notes, and prepare the feature to be shipped to staging.

Aim to Ship to Staging

The Staging application is an entire copy of the application meant specifically for testing new features. As developers code their features, their goal is to have their first version of the feature up on the Staging server about halfway through the Sprint. While not all cards will be done at this time, the goal of the developers is to have a good chunk of the work done so that the Product Managers can start their testing.

Testing and Fixing

As Product Manager start to test the new features, there are two outcomes. Either the features will be acceptable and will be approved, or the features will need some tweaks. If the features need tweaks, the product managers will send it back to the developers to fix anything that needs fixing. This cycle continues until everything gets approved.

Everything Approved for Production

The goal by the end of the Sprint is that all cards have been tested and approved by the Product Managers.

Ship to Production

After everything has been approved, the Production Shipper will ship all the features of the Sprint to the live production application ready for the public users to consume.

Sprint Demo

After the Sprint has been delivered, it's a time to celebrate. On bigger projects, one of the members assigned as the Sprint Presenter will put together a presentation to show the team everything that has been shipped. On smaller projects, the Sprint Demo is just a verbal recap of everything that has been shipped.

Because Scrum Express is a cyclical process, the Sprint Demo is usually combined with the Sprint Retro, and Sprint Planning for the next Sprint in one meeting.

Sprint Retro

Sprint Retro is usually a short verbal meeting where the team talks about how the Sprint went, any difficulties, and any potential improvements. Sprint Retro in Scrum Express focuses on processes improvements rather than specific features.

Product Management Meeting

The Product Management meeting is a weekly meeting that can happen at any point during the Sprint. It is a regular meeting where Product Managers groom the backlog. On bigger projects this is a 1 hour meeting (and sometimes happens more than once a week) and on smaller projects it is typically 30 minutes. (More coming soon).

Estimation Poker

Estimation Poker is 30-60 minute weekly meeting that can happen at any point during the Sprint but tends to work better the closer it is to the end of the Sprint (or beginning of the next Sprint). During Estimation Poker, developers get together and go through any newly added card in the Backlog that have not been estimated yet. The developers vote on how many "points" a card is worth in terms of efforts. We set our points at

  • 0.5 pts - 30 minutes or less of initial development
  • 1 pts - 30 to 60 minutes of initial development
  • 2 pts - 2 to 4 hours of initial development
  • 4 pts - 4 to 8 hours of initial development
  • 8 pts - 8 to 12 hours of inital development
If any card is worth more than 8 hours, it should either be an "off-sprint" card (read below) or split up into smaller cards.

Exceptions

Missing the Sprint

Coming soon.

Hotfixes

Coming soon.

Off-Sprint Cards

Coming soon.

Closed Sprints

Coming soon.

Headstart Cards

Coming soon.

This is a constantly evolving document, so check back regularly.
Aside from outright plagiarism and claiming that this is your work, feel free to use this in anyway you want.