Releasing a few new features may sound like a small task at first, but because we value stability and uptime so much, there are loads of things that must occur behind the scenes before we roll out the product updates you see each week.
Our goal is to release at least two updates to our main products each month. Other products receive pretty regular updates as well, but our IDX and CRM products receive the most attention by far since they’re the largest and most widely used. Each product update ranges in size, but usually contain 5-10 small changes or 1-2 medium to large changes.
We value transparency in everything we do and so we want to invite you into our process. We believe it’s important for clients to understand what’s in store for the future and be able to watch their tools evolve and improve over time.
Here’s a special behind the scenes look at our product development process.
Whether it’s a need to refactor something (i.e. rebuild to make it work even better) or build something brand new, it all begins with planning.
We use a system called Pivotal Tracker to store each individual item which has been green lighted for work, called a story. Each story requires it’s own set of directions, which usually includes written technical specifications and a wireframe or visual design.
Ideas are great, but we force ourselves to remain very realistic about upcoming product changes, and so we have a strict policy that our story tracking system only houses the list of items that will actually be worked on in the near future.
When we plan out new feature development, we rely heavily on what our clients are asking for. By using our Client Care team’s data we’re able to generate reports on common feature requests and suggested areas of improvement, and that plays a big part in deciding what we build next.
So far we have a list of stories but they’re not in any meaningful order yet, which means that it’s time to prioritize. We spend a good chunk of time ordering and re-ordering items, because the slightest change can impact many other things down the line.
Our rule is that any bugs which have been identified on the live product be worked on first, period. No matter how excited we are to add a new feature, it must wait until all open issues are resolved. The goal is to keep bugs to a minimum in the first place (see notes on testing below), but when they do come up it’s very important that they’re taken care of quickly.
After bug stories come features, and after feature stories come maintenance, and then we repeat the cycle again.
Now that our stories are lined up in order of what should be worked on next, estimations need to occur. This allows the development team to review the expectations of each change, ask questions and estimate how big or small a task is.
Of course estimating every single story takes time, but it’s so worth it since it allows us to be much more accurate when planning out our upcoming release schedule. We use a points scale of 1 (trivial) to 8 (major).
The value of using points estimates is that every developer on the team can agree on how many points a single story is, even if each developer has a slightly different completed points per hour ratio. This keeps the team in sync no matter who is working on which stories.
After our highest priority stories have been estimated, we begin building out sprints.
To us, a sprint is the amount of stories that we can fit into a single product release. Generally this will be approximately 4 days worth of work, but can fluctuate slightly depending on our goals for that release.
Once we have a reasonable amount of stories lined up for the sprint, work may begin. Since every single story has already been reviewed and estimated, we can feel pretty certain that we’ll hit our release target.
We have extremely high code standards, so our developers are consistently testing their code. Our build process ensures that work has been checked by at least three people in development prior to being delivered for final testing.
After all stories from a single sprint are finished and approved by our product lead, they are submitted together as a Release Candidate (or RC) to Quality Assurance (or QA). There is one member of our team in charge of all QA testing, which makes them the gatekeeper who has the final say on what is or isn’t approved for release.
Bugs are a natural part of programming, so we do everything in our power to squash them before the code makes it into production. If a single issue is found to be associated with any story in the release candidate, the entire product release will be held until all issues are resolved.
Once every story in a release candidate has been delivered, tested and approved; then we green light that release. This means that the version of that plugin gets bumped up to indicate a patch, minor or major release and the code is ready for production.
The entire TRIBUS team is notified of this change and our Client Care team works their way through every one of our Broker networks during off hours to update the plugins (on staging first for minor and major releases), check the site and ensure everything is stable.
If anything is ever even the slightest bit off, they revert to the last stable version and get a developer involved to investigate.
After we release an update, the work still isn’t quite done.
Our product documentation must always accurately depict the current features and functionality, so documentation updates are ongoing.
We wait until the release has occurred to ensure that the line between how things work now (product documentation) and what’s on the roadmap for the future (stories in Pivotal Tracker) remains crystal clear.
Our products are always evolving to meet the needs of our clients, which means that our documentation is too!
In order to support our clients effectively, our Client Care team must remain well versed on how our products work, so they receive notice of every release that goes out the door. For our minor and major releases, they receive some hands on training as well.
Once all sites have been updated, our Client Care team will add some new articles and videos to our Help Desk so that clients can immediately find relevant info on how to use their new feature.
Our Marketing team is also in charge of sending out a monthly email announcement that includes a roundup of new features.
Next, a few upcoming webinars will be added to the calendar to walk through the bigger changes, and proactive support will be provided to all clients who had been waiting on the feature to be released.
Clients can check out the full article on how to use our new Capture Forms feature here!
Now the work is officially complete on this release, and our team can move on to planning for the next.