Ever got to work and wondered how to start your day? Have you struggled to remember where you left over last Friday? Of course, a member of a team following Scrum should never be in that kind of position. Sprint backlog should be prioritized and the daily scrum should provide all the heads up one needs for the next tasks.

However not all teams start their day with the daily scrum, and nowadays not all team members are even in the same time zone, not to mention other organizational hurdles.

In order to address some of those issues, Flying Donut introduces the first of a series of dashboard updates that allows you to see at a glance a summary of the current state of your projects and highlight the cards on your work list that require your attention.

The main goals of the updated dashboard view are:

• Help you kick start your day
• Provide a high level view of all the projects you are involved
• Make it easy to notice issues early
• Enforce transparency

To achieve these goals, we have redesigned the view to include key metrics from each of the active sprints of the projects you are involved in. These include the sprint progress bar along with some cards showing the current state of the spring, the burndown chart which provides information about how things have gone so far and how things are developing for the future and a verbal summary about how this sprint is going. Of course, links to the project and sprint views are provided to allow quick navigation (an improvement requested by many of our users).

To complete this view, a list of the cards taken up by you is also presented to allow you to dive into a task directly.

We are already working on more dashboard updates to tie in with other Flying Donut features such as discussions and some of our future planned features such as impediments.

As always, we welcome suggestions and feedback from the community both on the current state and future direction of the product. So give the new dashboard a try and let us know what you think.

Happy Scrumming!
The Flying Donut Team.

As far as monitoring the progress of an agile project goes, the burndown chart offers a very concise solution. A burndown chart of an iteration is a plot of the remaining effort versus time. Having said that, there’s more to that simple statement than meets the eye. Bear with me, and I’ll reveal all the secrets of the Flying Donut burndown chart to you, showing you some extra stuff we’ve added, along the way: the Burdown Insight™, that lets you peek more deeply into the information behind the Burndown chart in a way that does not get in the way of its simplicity.

I will use the following burndown chart as an example, taken off the Pandamator project on Flying Donut. Click on “Details” to show the burndown chart.

All work done within an iteration should finish by its end. Given a reasonable estimate of the team working at a constant velocity throughout the iteration, the effort left should gradually decrease until it zeroes out at its very end. The role of the blue line in the chart (series “Ideal Effort”) is exactly to provide a steady-velocity measure against which actual work in the iteration can be compared. The slope of the blue line corresponds to the “Claimed velocity” shown on the chart.

Actual work, as measured by the amount of effort left, is depicted by the red line (series “Effort left”). The Burndown Insight™ takes over when you start looking at the red line. The slope from beginning to end corresponds to the “Actual velocity” shown on the chart. The red line goes down (or up!) as values for the effort left are updated by team members. Whenever total effort left does not change from day to day (and the dots on the red line stay on the same level), hovering the mouse pointer over the red line gives you an indication of “Stable”, like in the picture.

If total effort left has changed, you’ll see an indication of “Down N hours” or “Up N hours”, accordingly.

There are some hidden goodies in the Flying Donut burndown chart to complement this very basic information. Along the way, it also shows you exactly which cards were modified. Examples of that are shown on the examples above. Note that, while a downwards (or upwards!) turn of the red line by necessity implies that some cards were modified, the converse is not true: no overall change does not imply that no cards were modified. It might as well be that modifications cancelled each other.

If this feels like Flying Donut is actually keeping track of a separate burndown chart per card, this is exactly true. At some point, we might provide a way for you to look at the individual burndown charts.
I showed you some extra stuff, like I promised in the beginning, but you might be wondering where the secrets, I spoke about, are. Well, they aren’t so much secrets, as non-evident facts of how the burndown chart is calculated.

One of those facts is what happens when you start the iteration without having planned everything in detail. For example, some card does not have tasks, its tasks do not all have estimates, and so on. How is the burndown chart calculated in those cases? Rest assured that a burndown chart will be calculated no matter what! There is actually some default logic at play, to make up for the lack of detailed information.

• Ideally, tasks are there and they have estimates (or at least one does). In that case, the sum of the tasks’ estimates is the original estimate for the card.
• If no task has an estimate (or none exists), the original estimate of the card itself is used.
• If not even the card has an original estimate, then this card is not used in the calculation of the burndown chart.

One other non-evident fact about burndown charts is how to deal with new information. What happens when tasks are added or deleted along the way, is that the same calculation, as above, is done, and the burndown chart is modified accordingly. Meaning that the total original estimate is updated. Same thing happens if the end date is modified: the claimed velocity (the slope of the blue line) is modified accordingly.

That’s it! Now you know as much about the burndown charts in Flying Donut as I do.

Dear Flying Donut users and friends!

Our beta release has been live for three weeks now, and it is time to announce our free plan! 

By announcing the free plan, all of our fans will know how far they can go with the free version of our agile project management tool.

Screenshot of the plans

Let’s start by listing what all users get, regardless of the plan they choose. All plans come with:

• Unlimited Public Projects
• Unlimited Participants for Public Projects
• Unlimited Observers for All Projects
• SSL Protection
• Email support
• Community support

When signing up for Flying Donut you’re automatically enrolled to the “Free Donut” plan, which is our free plan of our agile project management tool. ‘Free Donut’ has a limit of one (1) private project with three (3) participants.

What does that mean in practice, and how far can a team of people go with the free version? Well, if it is a team of three people, then they can reach 3 private projects with 3 users. We don’t charge per user!

When the time comes, Flying Donut will charge on a private project basis and set a maximum limit to the participants of those projects. In case you’re wondering, a participant is a user that has read/write access to a project. After all, a user may be participant to one project and an observer to another. Each user can own projects and participate in projects they’re invited to. The bottom line is that the project participant limits are set according to the selected plan of its owner.

In addition, Flying Donut will be free for academic institutions, and students. If you are a student or a an academic institution and you are interested in Flying Donut, contact us at info@flyingdonut.io. Don’t wait until our software goes premium. You can do it right now if you wish.

And of course, an agile project management software that honors itself should offer a free trial period. Therefore, when you sign up for Flying Donut, your account will automatically participate in a 30 day free trial, which allows you to create an unlimited number of projects, and invite as many participants to the projects as you’d like. At the end of the free trial, your account will transition to the ‘Free Donut’ plan, unless you have selected a premium plan.

What happens to the existing beta users? Well, all accounts prior the the premium launch will enrol into the free 30 day trial, just like everybody else signing up at the same day. Of course, all data will remain intact, and no one will notice any difference.

You may find more information in our pricing page.

Keep in mind that Flying Donut is still in beta phase. We haven’t announced the premium plans yet. It is 100% unlimited free, until we go premium.

Enjoy!

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.