…are now visible directly on the iteration backlog.
At Agilebuddy, we’re heavy believers in sequencing. Once your stories are scheduled in a sprint, it’s important to be able to easily see which ones should be worked on first so that if you don’t finish everything, it’s the least important ones that get pushed to the next sprint. The order in which tasks should be worked on is usually pretty clear cut, but there are occasions when it would be helpful to define an explicit order for them.
Enter: Task Sequencing.
You’ll now see a familiar “Sequence View” button on user story detail pages. This will allow you to sequence that user story’s tasks. Tasks will now always appear in sequence order on that page and the iteration backlog as well.
Ever do this?
Me too.
Luckily, we won’t have to worry about it anymore:
You can now edit and delete your own comments from the “more…” popup, details pages and the Conversations tab on your homepage.
We’ve made some minor changes with respect to a user story’s workflow. Putting a user story in test or accepting it is now a little more flexible.
Before, when a user story’s last task was completed, the story automatically transitioned to the In Test status if there were failed acceptance tests or to the Accepted status otherwise.
Now, when a user story’s last task is completed, you will be prompted for the story’s new status and owner. This way, as a developer, you can easily put the story In Test (even if there are no acceptance tests defined) and assign it to a tester (who will receive an e-mail notification). The prompt will look something like this:
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 | 