Our Lean Agile Formula for Building Scalable Digital Products

Get a behind-the-scenes look at our Lean Agile process, tools, and tricks we’ve used to design and build mobile and web products for over 80 companies around the world.

5 years, 100+ projects, 30 employees. At Revelry, we build digital experiences to help companies go to market and scale faster than their competitors. The companies we work with go on to make their first thousand dollars with an MVP, or scale to generate millions and in some cases billions of dollars in revenue.

We’ve improved on Agile development methodologies to make our process leaner and more innovative. It’s a little different, but it works very, very well — and we want to share it with you because we believe it creates the best software (and it’s fast). We’ve optimized our workflows over 5 years and have developed a handful of bare-bones tools that automate repetitive tasks and shorten team meetings by more than half.

This guide includes:
An end-to-end explanation of our proven Lean Agile process
A cheat sheet with the exact tools and automations we use for repo setups, health tracking, burn tracking, and more
Links to Bot scripts to automate scoring and standup meetings

Exactly how we deal with 4 common issues that hit during Lean Agile development

If you already have an Agile methodology in place, we hope you’ll find some tools and tricks to help you make it even leaner. (We can also bring our process to your team.
Say hello to Team Revelry and let’s see what we can build together.)

Gerard Ramos
Founder & CEO

Lean Agile - Define Prioritize Create Test Release

Lean Agile Project Structure

Ship gold every time, 1 brick at a time

Agile is an iterative approach to software development that gained traction on the fringes of developer culture in the early 2000’s and has now become a mainstream method. As Agile practitioners we work in sprints, quickly shipping tangible and high-quality units of software one at a time, starting with the most crucial features and iterating on the product in the following sprints.

In our planning process, we imagine the whole system just long enough to lay out a few architecture rules to keep the system flexible. Then we place one solid brick down before deciding which brick to add next. And on and on until the castle’s built.

Older development methodologies imagine the whole castle upfront and plan every brick in advance. They work backward from their ideal end product, create a detailed spec doc, and go heads-down for a few months to develop the product. Unfortunately, by the time they resurface, business needs have changed. Or, the budget and deadline wind down while the product is still a pile of features that are 80% done. 80% done is worth 0 to a user.

At Revelry, we guard against this with a launch-and-iterate approach that’s extra transparent for our clients. We start with the product’s first grain of core functionality and sprint for a week; developing, testing, and launching a unit of 100% solid software. Then we check in with our partners, identify the next set of crucial features, and start the second sprint. We never create one be-all-end-all spec doc at the start of a project like traditional software consultants might, even though we do just as much planning. It’s simply spread out through the entire development project. We don’t predict; we adapt.

This frequent recalibration ensures that for each one week increment, the team only works on features that support the partner’s current business goals and the most urgent needs of their users.

This system also lets us rapid-launch products — we can get a working prototype or MVP out in the world in as few as 4 sprints. Many of our engagements last 3-6 months, while some partners work with us for up to 12 months to continue iterating. We keep our contracts flexible and invoice incrementally with each one week sprint.

Let’s take a look at how we structure projects with Agile, then dive into our unique process.

(It’s worth noting that we play nice with others. If a client is already practicing Agile and needs us to join an existing team’s workflow, we can support their methodologies with the techniques we’ve developed to create an integrated, lean process.)

A project is an epic

An epic captures a large body of work. It is essentially a large user story that can be broken down into a number of smaller stories. ~ Atlassian

An entire Revelry project is an epic. It might be an MVP web product, new mobile app, implementation, or digital marketing campaign. For example:

  • An app people can use while fishing to gather environmental data from photos.
  • A website the marine industry can use to source maritime equipment.
  • An implementation of our social media platform into Amazon.
  • A private social network for the PR industry

We break epics down by writing user stories, which are objectives a user should be able to achieve with the product (more on this in a second). Each user story is further defined by acceptance criteria (AC), a checklist of requirements needed to complete the user story.

We develop and launch user stories during each one week sprint. We end the sprint by writing user stories and scoring them before the next sprint’s kickoff meeting. Sprint 2 stories are written in Sprint 1, Sprint 3 stories are written in Sprint 2, and so on.

Lean Agile user stories at Revelry

We tell our clients that one of their most important jobs is to help us write user stories that capture their product vision. They are involved in this step and it’s a collaborative process where multiple people on the team will provide input and the business’s product owner signs off on the final story.

+ Create a Descriptive Title

All user stories start with, “As a ________, I want to________.” The user could be a developer, user, admin, system, bot, etc.

As a user, I want to sign in with my email address and password
As a developer, I need to setup my local environment
As a bot, I need to deploy the staging branch to heroku through codeship
As an admin, I would like to filter users by most recent sign in

These stories become issues in GitHub with a unique identification number. We manage progress in Waffle (a free Kanban board that automatically visualizes the status of your GitHub Issues).

+ Add Business Value as Background

We include business insights on our stories to help to clarify objectives. Many teams don’t do this, but it’s important at Revelry because it helps our developers and designers understand why they’re building a feature and how it’ll impact other pieces in the larger picture.


For example, if we write a story for a 3D printing interface like our client Entrescan, we’d include a note about the broader business context: Entrescan wants to open up 3D printing to people who are new at this and don’t have a printer at home. So, the interface needs to be really simple, and it has to work in a user’s browser without special plugins, to make it more accessible.

+ Unambiguous Acceptance Criteria

All stories must have acceptance criteria (AC). Anyone on the team can define AC, but the Product Owner (client) must sign off on them. These AC go to the issue description on GitHub as checkboxes.

We write AC as Given, When, Then statements designed to describe specific user behaviors which accomplish business goals:

  • GIVEN a specific state
  • WHEN I do a specific thing
  • THEN this specific things happens

For example the AC for the “As an admin, I would like to sort users by most recent sign in” story might be:

+ Add design sketches and screenshots


When possible, we also add screenshots or sketches of the desired outcome to add more context for developers and designers as they develop stories. Some companies leave this step out, but we think it’s important because visuals make it easy for our developers to be on the same page as our clients when it comes to their rationale for a story and how it’s connected to others.

How we score user stories

Once stories are written and approved, we need to figure out how difficult and complex they are so we can prioritize our resources for the next sprint.

This happens during the story scoring process, which estimates the amount of effort we’ll put into each story relative to other stories. Team members cast their personal votes and then we calculate the average score for each story.

A democratic process like this can take awhile, and it wasn’t uncommon to spend 2 hours on a scoring meeting at Revelry, which ate a lot of developer hours.

So we automated it. Our meeting time dropped to 45 minutes or less.

We built a Slack bot, /poker, that prompts each team member for their vote on a story, calculates the average, and moves on to the next story. The bot hides story scores until everyone has cast their estimate, so we don’t influence one another’s answers, then uncovers them with a /poker reveal.


It’s essentially a virtual, automated polling system that cuts out over an hour of inefficiency. This really adds up when you use it every week for a team of 3-6 people. Plus, we’re all in the meeting at the same time, but we can be on opposite coasts or in different countries and have an equal hand in the quick meeting.

The project process

Project Creation

We start most new projects with a discovery sprint to clarify business objectives, project goals, and user needs. We identify the most valuable features and define the smallest core piece of functionality the product needs. That’s where we’ll start.

The first 20 or 30 things we need to do to create a new project used to take hours or even a day to complete. Now, we have a slackbot that in about 10 seconds will: create the project in GitHub, add the Project Brief template, hook up the agile tools, set a bunch of permissions, and generate the first batch of stories.

Then we queue up the new user stories (write them, define AC, score them, and put them into GitHub) in preparation for the first sprint. If Revelry joins up with a client’s team while a project is already in motion, then that team needs to have the stories written and scored before the first sprint with Revelry.

During this phase we work with a client to determine a project budget and timelines. We don’t do fixed-bid pricing. Instead, we invoice for each sprint as we go along and work to keep the whole project within timing and budget constraints.

We also set up a Slack channel for that project and invite clients so that the whole team sees the conversation and development as it unfolds. This full transparency is another area where Revelry differs from typical software consultancies.

First Sprint

Sprint 1 begins with a Kickoff

+ Assign team
We assign a full stack team of 3 to 6 Revelry teammates needed for that sprint: a mix of architect, developer, designers, quality assurance, product, and producer. We sometimes create developer/developer and developer/designer pairs and place them into existing teams.

One thing that’s unique about working with Revelry is that you have access to teammates who have deep industry specialties. You can bring on a finance tech expert who used to work at Capital One, or someone from IBM, or even load up on designers if your project is design-heavy. We build you a team that’s the best in the business for that sprint.

Another important teammate is the Product Owner: usually a point person on the client’s team who serves as the ultimate decision maker on everything related to the product. On most projects, the Product Owner co-writes the user stories with Revelry and is–as much as possible–involved in the day-to-day of the sprint. If the client can’t play the role of Product Owner, we provide that as a service, bringing fully written stories to the client for approval and user testing.

+ Revisit stories
During kickoff, we revisit the stories we wrote and scored in the previous sprint, prioritize them, and make individual commitments to get ‘em done. We also make sure to:

  • List dependencies and potential blockers in the story’s GitHub ticket as check boxes.
  • Link up any stories that must be completed prior to work on an individual story using GitHub #issuenumber, which also calls out dependencies.
  • Assign issues to teammates that we need answers or feedback from.
Sprint time – How we work stories

We use GitHub for distributed version control and story tracking, and we use kanban board-style Waffle to visualize that progress (it connects to GitHub so it updates our stories automatically).

How We Work Stories

The story sits in the Backlog column until we move it to This Sprint during the sprint kickoff (when we form the commitment for the sprint). When an engineer starts working a story, they move it to In Progress. As they complete AC, they mark the check boxes.

Once all AC is complete, the code is scanned by Lintron, an automatic style checker we built. Lintron is a pull request robot that we update every time we create a new code standard, and it very consistently catches style and logic issues, freeing up human code reviewers to provide substantive feedback. The results have been great.

Revelry Lintron
Revelry Lintron

When an engineer has addressed Lintron’s notes, they move the story to In-Review and assign their pull request (PR) to a different engineer on the team (or in the company). Once the code is reviewed in-depth by a second Reveler, we deploy the story to internal QA. We use Codeship for automatic deployment and continuous integration, so any code that passes review is available for QA within minutes.

Internal QA

If QA finds an issue with any of the AC, they uncheck the box and send the story back to the engineer. In the case of a large story where just one AC is missed, we close the story and log a new bug. If an edge case arises in QA that isn’t represented by any AC, we log a bug. Once QA’s done we move it to user acceptance testing (UAT).

User acceptance testing (UAT)

One of our clients’ most important jobs, alongside helping us write user stories, is to do UAT and use the system every day. If there are issues, they send it back down the chain to engineers. Stories coming back from UAT are the highest priority so we work on them immediately. Getting time from our Product Owners (clients) is tough and when we have them in the mix, we make sure to address their concerns as fast as possible.

When the story’s complete in UAT, we immediately ship the new features to production through another automated deployment.

How we work Standups

Our daily standup meetings happen in Slack, and are complete in 10 minutes or less. We’ve seen many benefits: Slack is quicker than getting everyone on the phone, and managers can quickly skim through the notes on multiple projects to get their pulse.

We use the built-in Slack /reminder command to run our scrum meetings for us automatically. (Here’s a closer look at how we do it). It sends a reminder to the team to round everyone up and reinforce our scrum philosophy.

Lean Agile Slack Standups

Each person on the team answers the following questions:

  • What did you do yesterday? include issue number
  • What are you planning today? include issue number
  • How are you blocked? ask for help & set reminders
    • We note blockers and take them offline to be addressed. Do not solve problems on standups.
    • If we need to hash anything out face-to-face, we quickly jump on a zoom.us call.

All updates need to reference a specific issue number, and by the end of the meeting, we’ve updated all the stories to reflect their current status.

Lean Agile Sprint Wrap-up

During the week, we have also been writing new stories for the next sprint. Often we will run a session of planning poker at the end of the week to prepare for the next sprint kickoff.

Every other week, the team has a retrospective conversation. we discuss what felt crappy, what was awesome, and specific tactics to improve the next sprint’s communication or velocity.

Start Sprint 2

  • Kickoff
  • Build
  • QA & UAT
  • Write and score stories for Sprint 3

Rinse & repeat.

That’s how we do it, folks.

The Revelry guide to avoiding disasters

Let’s talk about how and when to escalate things to management. When you’re moving as fast as we do, there are 4 common issues that can derail progress. Here’s how we deal with them without ringing all the alarm bells and slowing people down.

(This problem-solving is the domain of the project’s Producer on the Revelry team, who is responsible for removing blockers, getting questions answered, and facilitating proper channels to solve problems during a sprint.)

Here’s what we tell our teammates when they come up against these common issues:

1. Stories that are more difficult than originally anticipated

If you’re an engineer or designer

  • Immediately ask questions you need answered in the implementation Slack channel, without at-mention pinging anyone, the moment you encounter something you have questions about.
  • Assume it won’t be answered and do your own research for 30-60 minutes.
  • If you have made no actionable progress in that time, at-mention ping someone to get attention on it.

If you’re a Producer

  • Watch out for hang-ups. Your projects should develop a cadence and you’ll be able to see how scored stories move through the workflow as projects progress.
  • When things aren’t moving at the normal pace, there may be a problem. e.g. a story has been in progress for too long, or if it’s stuck in QA. We share the issue in #firedrill channel in Slack without tagging anyone directly.

2. Stories you won’t finish by the end of the sprint

  • Sometimes, stories will roll over to the next sprint while they’re still in backlog. Alert the #firedrill @channel in Slack as soon as you realize a sprint commitment is at risk. Any stories that aren’t in QA 24 hours before the end of the sprint are at risk of rolling over.
  • It happens, it’s ok. Don’t panic. Stories rolling over are top priority for the following sprint and no other stories should begin until those are complete.

3. When a client asks for a new feature or change in AC mid sprint

  • This happens, but if you stick to the main standup process, this is easier to avoid. Features and AC changes can quickly derail a sprint and must be addressed immediately outside of a standup.
  • If it’s a simple update or addition of a single AC, the Producer will often update the existing story, as long as it doesn’t affect the difficulty score.
  • If the change is big enough, the PM will write a new story. The original story is now a dependency of the new story to be created — link them as such with #issuenumber.
  • If the request is for a new feature, 9 out of 10 times, we’ll create the story but put it at the top of the backlog for prioritizing into the next sprint.
  • For that 1 out of 10 times that we really really need to get the new story added to the sprint, we’ll do lots of handwaving to point out it risks bumping an existing story off the sprint commitment.

4. Communication with clients

  • We open our Slack channels to our clients for full transparency, and that’s where we communicate with clients so that everyone gets context and an awareness of the conversations that are happening.
  • 1-1 direct communication with clients should be reserved for sensitive or confidential issues that require privacy, and this should be rare to keep things running smoothly and transparently.

Tool Cheat Sheet

We use these tools to automate our development — try them out and let us know how they do.

  • GitHub – Story tracking
  • Waffle – Automatically-updated Kanban board
  • Standups in Slack – How we automate standups at Revelry
  • Codeship – Automatic code deployment and continuous integration
  • /Poker – Slack bot for efficient story scoring
  • Issue Bot — Slack bot for creating Github issues

That’s the Revelry way

That’s how we turn ideas into businesses. Our process isn’t set in stone and we improve it every day, but it has served us well: 70+ projects and growth fueled through amazing relationships, happy customers, and straight up hustle.

Stay true to the core principles of this Lean Agile process and you can’t go wrong:

  • Ship gold every time, 1 brick at a time
  • Give clients full transparency
  • Automate with lean tools
  • Individual ownership gets things done

Let us know if you try our process and tools. We’d love to hear from you. You can reach us via email at hello@revelry.co.

Let’s Build Something Amazing