Agile teams are small, highly adaptable cross-functional teams that work closely together to iteratively develop software in every release. Task prioritization and teamwork are important and necessary for Agile teams. However, when it comes to DevOps, there’s an even stronger need for collaboration and continuous feedback between the development and operations teams, and for transparency across the entire organization.

As a DevOps team, Hiptest recognized the need for a channel that enables open and transparent collaboration and communication on tasks ranging from creating user stories for features, to writing abstracts for the next tradeshow. Read on to find out how Hiptest currently manages its product development using Trello, Atlassian’s web-based project management application.

Our Principles

Before starting, it’s important to note that there isn’t a universal solution for this problem. This is not a panacea for every team in every stage of its software development journey, and the “one size fits all” philosophy will not work here.

Even the way we work today at Hiptest, is not the way we worked in the past and it will not necessarily be the way we work in the future as we begin scaling our operations. This just happens to be the right process for us now.

There are two main principles that guide us when we work on our processes:

• Small batches of work are better than big batches (lean)
• When a feature is “done”, it means that the feature is deployed into production. We believe that there is no value in having completed code that isn’t deployed into production

As a DevOps team, Hiptest continuously deploys new development into production. We deploy between one to ten small increments every day. This enables Hiptest to get early feedback from users, do A/B testing, resolve bugs faster and react quickly to changing customer requirements.

Using Trello to Manage a Lightweight and Transparent Roadmap

Hiptest believes that working in short iterations (usually two-week sprints) to validate the team’s long-term vision is more ‘Agile’ than creating a comprehensive, detailed plan. So, our team manages a lightweight roadmap within three timeframes:

• Short-term: The exact details of the work for the next four weeks, which include the current two-week sprint and the next, are well-planned and scoped out.
• Medium-term: The work for the following few months are planned, in the form of high level features.
• Long-term: The work anticipated beyond a year is clearly speculative, so time isn’t spent on planning for it.

Thus, the backlog of work that is created is the result of our vision, or what we believe in, and the feedback we receive from the market and our users. We tested a couple of tools to find one which manages our backlog the best, and finally adopted Trello. Like Hiptest, Trello is simple, efficient and cost-effective.

Trello helps us manage our themes, features, user stories and issues. Our roadmap is transparent, and we love sharing it with our community. So, take a look at our short-term and medium-term priorities on Trello, as well as the stories we are working on right now.

We also use a whiteboard in Trello to manage our Kanban for the current sprint. It gives our team a high-level view of the Work-in-Progress (WIP), so that with a quick glance, anybody can have a general idea about the jobs to be done and the anticipated timeline.

Our backlog

Our vision is broken down into 9 major themes organized by colors: yellow for test automation, orange for test refactoring, red for bugs, purple for integrations with other platforms, indigo for test execution etc. Each theme has a specific business goal. Each feature is assigned a colored label according to the business goal it satisfies, which immediately shows what theme the feature belongs to.

At Hiptest, we believe that the product manager is highly responsible for the overall quality of the product. So, before starting any work on a feature, the product manager has usually defined the acceptance tests. Since we are strong advocates of Behavior Driven Development (BDD), we believe the following about test scenarios:

• Scenarios are requirement specifications that also behave like executable acceptance tests
• Scenarios are the definition of ‘STOP’ for developers
• Scenarios are preferably written prior to development and based on a business domain language
• Scenarios are confirmed with stakeholders and are automated
• Scenarios should follow the DRY (don’t repeat yourself) principle
• Scenarios should be reviewed and refactored continuously, just like code

This enables our team to work with readable and maintainable test scenarios. If you’re interested, learn more about our testing philosophy.

Integration with Hiptest

We use the checklist in Trello to link the acceptance tests created in Hiptest with a feature in the backlog. The linking is done by dragging and dropping the test scenario URL from Hiptest into the checklist area for the feature in Trello. This way, any team member can access the Hiptest test scenarios from Trello just by clicking the URL in the task. Today, we manually mark the Trello task complete when the test passes as is not yet synchronized with the test status in Hiptest. This synchronization is certainly an opportunity for improving our team’s experience in the future.

What happens when a feature is done?

When a user story is developed, and all the tests have passed, the new software developed is automatically deployed into production. The task is done, and everybody can pat themselves on their backs!

Once this happens, the story is automatically archived. Basically, it disappears from the Trello board together with the links to the specific test scenario in Hiptest. Although the task won’t be visible in Trello anymore, the acceptance tests exist as the living specification of the deployed working software in Hiptest. That’s why it is very important to have readable tests that are refactored frequently!

What’s next?

We plan to share our project Hiptest4Hiptest with the community, so that everyone will be able to see the acceptance tests and give us their feedback even before we start development. You will also be able to see our living specification; all our acceptance tests along with the results of the last build.

This is where Hiptest stands today. We would love to hear how your team drives its product development and any comments, suggestions or criticisms about our practice!