At Botmetric, we are on a mission to simplify the cloud management operations for businesses across the world. We embarked on this journey in 2014 and have made great progress with acquiring worldwide customers ranging from fast-growing startups to Fortune 500 companies.
As a born in the cloud company, our development process from day one was to be agile and lean for faster iterations with constant feedback from our customers. However, as we built our SaaS platform and delivered our initial versions of the product platform, we encountered set of challenges related to growing complexity of use cases and team size in reducing the overhead of sprint based development process.
During April 2016, we switched to ASANA for our team collaboration and managing our sprint based agile development process with following principles:
1) Asana projects for organizing product roadmap, backlog, and wishlist:
We setup a product wishlist and product backlog projects to capture the future use cases, customer requests and internal product roadmap items. Any work item where we have enough details and can be considered for development is added/moved to product backlog project where all others are hosted in product wishlist project. We have a high level product roadmap project that tracks key goals to be achieved during a specific month, quarter, and year.
2) Every sprint is a short lived project:
For every active sprint, we create a new project with notation “Year-Month-Product Engineering-Sprint Name” and the completed sprints are achieved to reduce the clutter. We use Sections in Asana for grouping different work items under our different components for clarity. We use Asana support for work item description to capture the relevant user story and add sub tasks under it.
3) One DEVELOPMENT sprint followed by one EVOLVE sprint in a month:
We have ditched the traditional development sprints in a loop approach, with one focussed DEV sprint where new requests or features are implemented based on product roadmap & backlogs followed by one EVOLVE sprint where we work towards improving our earlier releases based on usage data and customer feedback. Our typical description for EVOLVE sprint is as follows:
This sprint will focus on enhancements, improvements, and customer requests before any new feature development. Any critical support tickets that are showstoppers can be added to this sprint. We will focus on work items from Product Roadmap and Product Backlog that will help us improve the value, benefits and experience of our end customers/users.
4) Every work item in a sprint has to pass our 3-key-questions test:
Our approach to moving items into a sprint is based on three key questions. We ask questions like:
a. “How does this work item/feature request help our customers?”
b. “Is this the most important thing that we should be doing now?”
c. “Are we clear how we will go about building it and it’s impact?”
We encourage our engineers to understand, answer and document as description in Asana. Our engineers write short descriptions for each work item in Asana that will in-turn be used by QA & product marketing teams to understand what is coming and why we are doing it.
5) Sprint delivery quality is what matters:
We focus on the quality of delivery from our sprint more than the speed of development as a key metric during our sprint review and closure meetings. It helps us stay focussed on delivering better customer experience over more features. We use the second half of last Thursday of the sprint for a review and closure meeting while Friday will be used for planning the next sprint, including detailing all the work items with required description, dependencies, sub tasks, tagging, etc.
Why we love Asana and how it simplified our engineers’ lives?
- Better collaboration: With Asana’s support for tags, notifications, and ability to create sub tasks for a work item has further improved the collaboration during the sprint planning and execution. Also, any discussion related to architecture, implementation approach, QA, etc, are opened as discussion threads to capture the outcome and meeting details. We include tags like year, quarter, month, feature priority, new feature vs. bug vs. improvement for quick filtering by different stakeholders.
- Shortened standup meetings (2 mins to max 10 mins): Our daily standup meetings have become shorter, with some lasting for just a few minutes to a maximum of ten minutes, for a team of almost 15 engineers. One thumb rule that we follow is, people will raise a concern only if they are blocked or need help else we are good to start the work without wasting time on verbal updates as relevant engineers can update the same on work items. The daily standup meetings are run by different team members in rotation without any designated owner so nobody is waiting for the sprint owner to manage it.
- Low overhead and delighted engineers: One of the coolest things about Asana is that it doesn’t enforce any agile and sprint process overheads. The user experience of the app and the quick responsiveness of Asana makes it a delight for us who have tried other bloated tools for agile and sprint management 🙂
Even our marketing and sales team have applied the same process by moving into Asana for organizing their work with a similar philosophy. If you are a startup, then we would highly recommend you to evaluate Asana for it’s no frills approach in letting you do what you want without enforcing constraints. If you are already using Asana, then share your thoughts and experience with us on Twitter, LinkedIn, Facebook.
Editor’s Note: This blog post, ‘How Botmetric Uses Asana to Speed-Up Sprint-Based Development Process’ is authored by Vijay Rayapati, CEO at Minjar Cloud Solutions Pvt. Ltd.
