First there is no “one size fits all”. So the way we work today, is not the way we did work in the past and not the way we will work in the future as we are scaling our operations. It is just the right process for us now in our startup.
Secondly, they are 2 main principles that are guiding us when working on our process:
- Small batch are better than big ones (lean startup).
- Done for a feature means it is deployed in production. The value of a code not deployed in production is 0.
So we are a DevOps team and we deploy continuously new development into production. We deploy between 1 to 10 small increments every day. It enables us to get early feedback from users, do A/B testing, react quickly when we have to deliver a bug fix…
Short iterations (2 weeks sprint) to validate our long term vision matter much more than a detailed plan. So we manage our lightweight roadmap with three timeframes:
- The next 4 weeks (current sprint and next one) are pretty solid.
- The following few months are planned, with high level features.
- Beyond a year is clearly speculative so we don’t spend time on planning.
The backlog is the result of our vision (what we believe in) and the feedback we have from the market and our users. We’ve tested a couple of tools to manage it and we have adopted Trello: it is simple, efficient and cost effective (like Hiptest 🙂 ).
With Trello, we manage our themes, features, user stories and issues. Our roadmap is transparent and we share the biggest part of it with our community. So, you can look at our short and mid term priorities on Trello, as well as the stories we are working on right now.
We also use a whiteboard to manage our Kanban for the current sprint. Trello just give a high level view of the WIP (Work in Progress).
Our vision is broken down into 7 major themes organized by colors: test automation, refactoring, integrations with other platform… Each theme has a business goal. Then each feature of the board has a label (color) that shows immediately which theme it belongs to.
We believe that the product manager is responsible for the overall quality of the product. So before we start working on a feature, he has usually defined the acceptance tests. We are strong believers in Behaviour Driven Development (BDD):
- 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.
Learn more about our testing philosophy.
We use Trello checklist to link acceptance tests with a feature. We drag & drop the scenario URL from Hiptest in the Trello checklist area. So any team member can access the scenarios from Trello just by clicking the task. Today we manually mark the task as completed when the test passes. It is not yet synchronized with test status in Hiptest. Certainly an improvement for the future 🙂
When a user story is developed and all the tests pass, it is automatically deployed in production. It is done!
So the story is archived. Basically, it disappears from the board together with the links to Hiptest. In this case the acceptance tests within Hiptest remain the live specification of the working software. That’s why it is so important to have readable tests and make sure you refactor them continuously!
We plan to share our project Hiptest4Hiptest with our community so everyone will be able to see the acceptance tests, give feedback before we even start development. You will also be able to see our live specification: all our acceptance tests with the result of the last build.
This is where we stand today. We would love to hear your story bellow and challenge our practice!