Why we run a daily all-hands meeting
Presenters use our product at their most vulnerable — speaking in front of a group of people. That drives us to identify and fix bugs quickly.
Poll Everywhere is a SaaS company centered around live-polling, serving over 75% of the Fortune 1,000.
What happens
Each morning, at 10 o’clock sharp, the entire company gathers around a giant TV. For two minutes, the most pressing issues and announcements are shared, in a video call with our remote employees.
One person owns this meeting, typically one of our product managers Brian Goodman.
Here’s the rundown
[ Automated computer voice at 9:59 AM ]
Stand up begins in 1 minute
[ PM ]
“Alright, It’s 10 o’clock, let’s do this. Good morning everyone…”
[ The entire company in unison ]
“Good morning Mr. Goodman”
[ PM ]
Customer support, any critical bugs?
Upcoming Releases?
Any Blockers
Stories awaiting review?
Any Announcements?
For each step, there’s only one person responsible for speaking up.
We rarely take longer than 3 minutes. This amazing feat is made possible by Chopper.
Chopper surfaces important things that may stop the line. If PE was a person, and you asked “how are you doing today?”, it would point to Chopper.
What does Chopper show?
- Parts of our product that may impact retained revenue
(new releases, major bugs, seasonal events, etc) - Bugs, and teams working on bugs
- Blockers (things that prohibit other’s work, eg. broken development environment)
- Announcements, special peeps in the office, last day for XYZ
Critical bugs
We have labels in Pivotal for each of our main projects. In addition to having bugs in each of these projects we also have a label for critical user facing bugs.
Any time there is something in this category we stop the line until it’s resolved. This doesn’t happen often but when it does it’s a great way to surface this important information to the rest of the company that doesn’t deal in code day to day.
Upcoming releases
This is a simple query that fetches the “release” story type and sorts them by descending dates. We reserve announcing releases for user facing features since the rest of the company shouldn’t have to care that we’re bumping our version of MySQL or completing an AWS maintenance chore.
Blockers
We have an internal label that identifies stories as blocked. However, Pivotal Tracker fairly recently made that into a first class feature of their stories, so we’ll probably update our query to use that instead.
Stories awaiting review
These two sections are mostly for story review hygiene and to make sure people know when they’re expected to review work. It shows the names of people that have unreviewed Pivotal Stories older than 1 day and Stories left rejected for over 3 days
Bug thresholds
This is by far the most iterated on section of our stand up dashboard. Our bug pay down system has been through a huge number of iterations before we found something we liked and that held us accountable.
The first part to understand is that not all bugs are created equally.
We have severity labels for how negatively they affect the user experience of the project. The labels are described by how long we expect before the fix is in production (week, month, eventually).
Each project chooses a threshold for quality that the owners agree to maintain. That involves documenting how many bugs of each severity they allow in their code.
If those thresholds are exceeded at the time of our company wide weekly meeting, they must drop their current work and spend the next week doing nothing but fixing those bugs.
Security thresholds
This is the newest edition to our Chopper dashboard. It’s in an experimental stage and is modeled after the bug threshold section. It lets us know how many security issues we have categorized by severity (high, medium, low).
How does Chopper work?
We use Pivotal Tracker as our system of record for user stories, bugs, chores, and product releases.
Although you can query many ways in the Pivotal Tracker UI, we found ourselves asking questions that couldn’t be answered there.
Luckily for us, they have an API that exposes a lot of the information we need.
Our Chopper board is built on a few simple queries to their API.
Is Chopper right for your org?
We’ve made some difficult decisions around using Chopper, and there’s some large tradeoffs to consider. We’re optimizing for reaction time to bugs and blockers, and reducing churn.
Chopper is unique prescription to solve the growing pains of a SaaS company our size. A subset of Chopper may help your team save time and increase visibility.
Want a copy of Chopper? It’s closed-source right now, but DM us and we’ll give you the Pivotal API deets.
