The "Flying Donut – Operations" project is now public

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
As far as deployment is concerned, since we have been following a continuous deployment model from the beginning, we couldn’t do anything less in this case: all resolved issues will be pushed to production in short intervals. What was missing was a way to handle this process in Flying Donut, since the changes would be pushed during an incomplete iteration. We started browsing the GUI and after a while the answer was right there in front of us: the “Review” page. We had an approval mechanism that we could use when pushing changes to live. We would mark an item as “approved” and people would know that those items have been deployed on our live environment, ready to be used.
We decided to assign the following semantics: “Done” means that coding and testing is completed, “Approved” means that the change has been pushed to live.
The iteration after its start in review mode
That is what a user will see when they visit the execution…
The iteration after its start in execution mode
After having followed this process for a week, we decided to make the “Flying Donut – Operations” public, and share it with the people that have an interest in the progress of their suggestions and issues.
The project has now been finalized and below are the principals we followed:
  • 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.


In order to view the project just click on the link or visit the and go to the public projects.
We hope you’ll find this an interesting showcase of how Flying Donut can be used to organize and track support and operations tasks!
The "Flying Donut – Operations" project is now public

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s