Since we started CalcuQuote, we’ve been doing at least monthly releases packed with new features. Here’s a peek at how our product team continues to “wow” with the speed and efficiency of incorporating customer feedback into new releases:
It’s a Sprint, not a marathon
CalcuQuote releases are not an abstract future date. Instead, we organize our updates into four-week “Sprints.” This means that any requirement, big or small, must be broken into a managable chunk that can be delivered by the end of the sprint. Sprints typically break into four weeks: first three weeks are development and testing of individual stories, fourth week is dedicated to an all-hands-on-deck, end-to-end testing of the application. Week four is also when we plan out what will come in the next sprint.
We make stories turn to life
All of the development work we do starts off as a story like “As a CalcuQuote user, I’d like to…” The reasoning behind this is that everyone in the organization should understand the purpose behind what they’re creating and relate to what the user wants. As a result, conversations around stories get scoped in very plain-english terms like “If the user wants to see the text more prominently, would that mean a bigger font or brighter color?” This also makes it easier to focus on the most important thing: how would our customer find value in what we’re building.
Eye on the ball
Software development can be fun, and it can be easy to go down the rabbit hole of all the cool things you can do. Instead of focusing on technical, over-engineering of an easy problem, we focus on how we can deliver value to a customer. To keep visibility on this, we maintain all stories on a live, interactive board. Using Microsoft’s visual studio, each story is tracked with revisions, Q&A, test criteria, estimation of effort, etc. Most importantly, there’s a clear feedback loop if we ever get stuck on something, so we can keep the lines of communication open between product development and customer feedback.
Definition of Done
As a story passes through each phase of the product development cycle, we have clear definitions of what it means to be “done” with each step. This keeps everyone on the same page because “done” from a developer’s perspective is different from “done” by a tester and “done” by the customer support team which has to communicate the change to customers.
Continuous Improvement
At the conclusion of one sprint and prior to the start of the next, we have a “Sprint Retrospective” meeting. This is an all-hands meeting where we engage in an open dialogue about how things are going. That can mean highlighting processes that seemed to work well, giving a shoutout to someone who stepped up, or identifying things that are not working. Typically, each person frames their input in terms of “Start, Stop, Continue” – what should we start doing, what should we stop doing and what should we continue doing?
