London, UK; New York, NY; Cluj, Romania
Masabi is a UK-based startup specialising in mobile ticketing. Their JustRide Platform is an innovative fare collection system that enables transit agencies — from London to New York to Los Angeles — to offer convenient mobile ticketing applications to their riders. With such a diverse clientele and a growing suite of product offerings,
Masabi must tackle such challenges as: designing and maintaining a user-friendly mobile applications; maintaining integrations with numerous 3rd party systems; and tracking the storage, maintenance, and delivery of their associated hardware solutions. In order to track his team’s efforts in building out the JustRide data and analytics platform, Masabi Product Manager Jonathan Hyde turned to Clubhouse.
After a competing project management tool left him feeling like he “just wanted to throw (his) computer out of a window”, Jonathan stumbled upon Clubhouse.
As he compared it with other options on the market, as an alternative to JIRA or Trello, he found that the tool offered a simple interface and the high-level visibility that he needed to manage his team. And his team immediately loved using it.
Once they’d agreed on Clubhouse, Jonathan set about refining his team’s process and mapping it to the tool.
Planning starts at the Story level and is focused on a desired outcome. From there they begin to add associated Tasks. They work against the Rule of 3: If the Task represents more than 3 days of work, it becomes a Story.
If there are more than 3 Stories that come out of that, then they are rolled up into an Epic. Tasks should be 1–3 hours of work, Stories should be 1–3 days, Epics should be 1–3 weeks, and Projects should be 1–3 months. For them, Projects represent products or ongoing efforts and can comprise numerous continuously deployed apps.
In terms of estimation, the team used to estimate points and do t-shirt sizing, but quickly abandoned the practice as they felt that they were gaining little benefit from the time it was taking. They also only use due dates if there is an outside stakeholder waiting on the delivery associated with the Story. As a Story often represents a collaboration between two or more team members, the teammates are encouraged to assign multiple Story Owners.
Like many growing organizations, Masabi is flexible in allowing different departments to select the productivity tools that work best for them. As a result, Jonathan sometimes finds he needs to sync a Clubhouse Story to another department’s project management tool. He accomplishes this by creating one ticket in the other department’s system to represent the Epic on the Clubhouse side, and then he assigns that ticket to the member of the other team, so that everything is contained and manageable.
Jonathan and his teammates have also found the time to build out useful tools to extend the power of Clubhouse. They have a bot associated with their Continuous Integration software to report deploy information and they’ve published a Ruby script for simple CSV exports (found here).
When it comes to maintaining their Clubhouse organization, Jonathan says, “I am of the school of product management that says ‘My job is not to write Stories.’” He trusts his team to create whatever Stories they need to complete the goals that they’ve identified in the their planning process.
The team has a monthly meeting to review their backlog Stories and decide what goes into the next sprints (which are organized in backlog workflow columns), and he otherwise tries not to move other teammate’s Stories. However, as a rule of thumb, if a Story hasn’t been touched in 6 months then they will archive or delete it.
For teams just getting started, Jonathan has three (of course!) pieces of advice: