Since the launch of the Flying Donut we have received several questions, suggestions and of course minor issues.

We started thinking how to notify people that the issues they reported were resolved and live. We have always used Flying Donut to manage our internal processes, but it was the first time we were going to share this work with others. A lot of our team members have used issue tracking systems before (such as Jira) to share this kind of information, but we thought that the simplicity and agility of Flying Donut would be a good fit for this use case.

So we decided to go for it, and apply Flying Donut’s virtues to the operations domain. The project would be viewable by the public, and at the same time useful to us.

The main question was how to use a tool, that is designed with the principles of scrum, in order to handle support and operations, an area that can be considered as an ongoing project, where the “kanban” methodology seems more applicable.

After some brainstorming we created the project and decided to go with weekly iterations and rotate people in the “support and operations” role. The next step was to organize our work, so we went to the “Backlog” and created the two obvious backlog “Buckets”: “Issues” and “Suggestions”. All feedback we’ve received so far was placed in the appropriate bucket.

The backlog after a week of work

The iteration after its start in review mode

The iteration after its start in execution mode

• The “goal” of each iteration is to resolve the items in order of priority. If the team is not able to fix the items at the bottom those items will be moved to the next sprint.
• A “continuous” deployment model is followed. When an item is scheduled to be deployed (or is deployed) it will be marked as “approved”.
• Items that have not been “started” may have their priority order changed.