We just made a small change to how weekend days are handled in the burndown graphs. Previously, we would always show weekend days in burndowns, even if no work was done which would cause your burndowns to “flatline” every weekend. Now, if no work was done on a weekend day, it won’t be included in the graph.
So for those of you who are weekend warriors, you probably won’t see any change. For those of you who believe in sustainable pace ;) you shouldn’t see any more “flatlining.”
Well, Markdown actually. What I mean is, you can now use Mark down to mark up your descriptions in Agilebuddy.
So any time you see this, it means you can use markup:

You can click the Markdown link to view a cheat sheet of the syntax.
Here’s a little sample of what’s now possible in a bug description:

A change we had to make to accommodate markup was add Title fields to user stories and tasks. Since descriptions now support markup, displaying marked up text in a backlog view doesn’t look very good. So we needed every item to have a non-marked-up field that we could display in backlogs. You can view the description by clicking the more… link or going to the details page for that item. Titles are required and descriptions are now optional. Note that bugs already worked this way.
Existing user story and task descriptions have been moved to the title field for you.
For API users: titles are now a required attribute when creating user stories. We’ve made the API backwards compatible so that if you have a client only sending the description, we’ll simply use it as the title instead. Note that the title has a 255 character limit though, so we urge you to update your clients appropriately.
Some of you may have noticed that Agilebuddy only tracks the time you’ve spent on a bug or task since the last time you marked it in progress. It wouldn’t tell you the cumulative time spent if you started and stopped it more than once.
![]()
This was fine for the ideal case where you have a short task and you start it then finish it in one shot. At Agilebuddy, we don’t eat or take breaks so this worked perfectly for us. But apparently some companies allow lunch and coffee breaks so it’s plausible that slackers might need to stop a task in the middle of working on it. Well, Agilebuddy’s got your back on this one. It will now track all time spent on a bug/task even if you stop and start it multiple times.
Expect some even awesomerer time tracking features in the near future as well.
Of course, I’m kidding about the eating and taking breaks stuff. This feature really should have existed a long time ago and I was just trying to come up with the most outlandish excuse possible for its absence. Hey, better late than never!
Two new features today!
First, you can now export acceptance tests to CSV. They simply come along for the ride when you export user stories. While CSV is not designed for hierarchically-structured data, we were able to squeeze user stories, tasks and acceptance tests all into one CSV since they mostly share the same fields. We simply added a type column so you can tell them apart.
Secondly, we’ve added a Creator column to all user story backlogs so you can now tell who it was who initially added a user story to Agilebuddy.
Not much to say about this one…Acceptance Tests now have ID’s!!! What? Too many exclamation points?

Here at Agilebuddy, we mostly work off of the backlog pages and our home pages. On those pages, every action you can perform on an item is conveniently available.
However, as a few customers brought to our attention, a few actions were missing from items’ details pages. Namely, Delete and status transitions (start, stop, resolve, accept, etc.) So before, all we had was Edit:

Now, on the details page, you can do anything you can do on the backlogs and home pages:

Have you been missing comments your teammates have left on your bugs, blockers, user stories or tasks?
Well, no more!
You’ll now receive an e-mail notification whenever another user adds a comment or attachment to a bug, blocker, user story or task that you own. The same goes for acceptance tests added to a user story you own.
Please feel free to leave a comment on this post letting us know what other kinds of notifications you’d like to see in Agilebuddy.
At Agilebuddy, we’re pretty diligent about breaking down our user stories into small tasks and estimating them in hours. So we get lots of use out of the task hour burndown charts. A few customers work a little differently though and told us they really needed a story point burndown because they mostly worked at the user story level rather than the task level.
We thought it was a good idea, so we added a Story Point Burndown to the iteration page:

You can now switch between the hours burndown and the story points burndown and Agilebuddy will remember your preference.
Home | Features | Tour | Resources | Signup
About Us | User Guide | Consulting |