Priority review boards: a simple process with a big impact!
Developing software is hard. You need to balance the needs of the users, the needs of the business, your current bug count, and more. You constantly have to prioritize what to work on, and make it fit with the resources you have available.
If you’re a solo developer / entrepreneur, this is fairly easy to do. Once your team grows, it gets harder.
New stories — bug reports, feature ideas, or development chores — pop up all the time. If you don’t have a way to triage them quickly, they can be very distracting and kill your team’s productivity.
Without constant gardening of the backlog, cruft accumulates, and projects lose momentum.
At Balsamiq, we have a simple process to help us stay on top of it all, which we call Priority Review Board, or PRB for short.
What is a Priority Review Board?
A PRB is a group of people who are tasked with regularly reviewing current and incoming engineering work for a specific product.
The group is made up of the following people:
- A Product Manager — to help prioritize work. They often lead the Board.
- The Customer Support Lead — they can explain what the new stories are about, and help prioritize. They’re the voice of the customer.
- The Development Team Lead — they know how projects in development are going, and how busy each developer is right now.
- The Quality Assurance Lead — they have their finger on the pulse of the current status of the backlog.
That’s it. Only 4 people, to keep it as efficient as possible.
There’s no one from Design, Research, Documentation, Marketing, Sales, Legal, Operations, etc. This is because the PRB only exists for prioritizing, nothing else.
The PRB has a Slack channel for urgent things, but its main task is to have a weekly PRB meeting together. We do it on Mondays, and it only takes us 30 minutes each time.
How to set up a PRB
Other than agreeing on who the 4 members are, you need the following.
Three separate lists for stories:
- An inbox - the list of new stories to review.
- A backlog - this is the list of stories that are current, or approved to be worked on.
- An icebox - a list for things we may work on in the future.
Your product team needs to agree on these 3 simple rules:
- New ideas go to the inbox immediately, with no discussion — this one is hard to do, especially for new feature ideas… they’re so juicy and fun to think about! 🙂 You need discipline here.
- Only PRB looks at the inbox and has the power to move things to the backlog — the fact that PRB includes all the important stakeholders makes this acceptable to the rest of the team. If you really want to push for a story, tell your representative and they’ll fight for it at the next PRB meeting.
- Stories in the backlog are pre-approved, and up-for-grabs — developers don’t have to worry about prioritizing, they know that if something is in the backlog, PRB has decided that it’s OK to work on it next.
How to run a PRB meeting
We usually follow this 3-step process:
- We review the status of all current projects in development.
- We review the current stories in the backlog (we use Pivotal Tracker).
- If appropriate, we pick new stories from the inbox, to work on a soon as a developer is available. We move the others to the icebox.
How do we decide which stories to pick each week? Well, it depends, but we wrote this article that sheds more light on the subject.
This allows us to discuss any blockers, any urgent new story, what the development team’s current focus is, and make decisions together on how important each new story is.
That’s it!
I know, this may seem obvious to many of you, but you’d be surprised at how such a simple process can have such a big impact on team speed, cohesion, and morale!
Once you have a PRB in place, you can also use it for roadmap planning, project scheduling and staffing, icebox gardening, and more!
How do you solve product team alignment on your team? Send us some feedback below!
Peldi for the Balsamiq Team
