Behold the FogBugz landing page:

In its default form, this page is very useful to people desiring to log on to FogBugz.  Outside of that, it’s potentially useful as a portal for external users to access documentation and file cases, however the scope of that usefulness is limited by its lack of customizability.

Or rather, it was limited. 

In the advanced section of your FogBugz site configuration, there’s a new option for selecting a custom landing page. 

All of your publicly-visible FogBugz wiki pages will be available on this list- simply choose one and it will replace the default landing page.  I've selected the 'Project AwesomeCat' wiki to be my landing page.

If you’ve done nothing other than select an existing Wiki as the new landing page, then visitors to your FogBugz site will see something relatively like this:

Save your Oooooo’s and Aaaaaah's for just a moment-  there’s something significant about this screenshot.  See that little Log On link in the corner?

The only thing about this custom landing page which is not fluidly customizable is that little Log On interface, and even that could be altered with a little bit of jQuery.

The mechanism for customization is now the FogBugz wiki: Your landing page will look exactly like its corresponding wiki page... In fact, they're the same thing. To alter content, alter the wiki page.  To change the look and feel, visit the wiki customization page and edit your wiki’s template:

You can view the thrilling conclusion of the Project AwesomeCat custom landing page at LandingPageDemo.FogBugz.com

As a more practical example, these same techniques are in play over at Developers.Fogbugz.com  

This is a call for beta testers interested in trying out our new version control product: Kiln (http://www.kilnhg.com/). Mercurial is the version control system under the hood, so if you've got FogBugz and wanted to try out a DVCS, this is a great opportunity. If you just want to experience the awesomeness of version control, code review, and bug tracking all working together seamlessly, this is a great opportunity.

I have to mention that this is a beta. There will be some bugs during installation, and possibly after. The good news is that Kiln has been running for several months and hosting production code for a bunch of people in the On Demand environment. We think the risk is pretty low, but as software developers you know there is no way for us to guarantee that there won't be bugs.

We are specifically looking for licensed (install it on your server) testers, although you can use the same form if you're a FogBugz on Demand customer (the more the merrier!):

https://shop.fogcreek.com/beta-kiln/

Licensed Kiln will only run on Windows 2003/2008 Server with SQL Server 2005/2008/2008 Express. Folks running other operating systems or database servers are out of luck for the time being.

ONE MORE THING: This release also introduces a new version of FogBugz. There have been a few UI changes to support having FogBugz integrate with other applications. If you don't want to test Kiln, but would be willing to test the new version of FogBugz, send me an email to jason (at) fogcreek (dot) com.

Manicwave Productions has just released Tickets (v1.0), a Mac OS X client for FogBugz. It provides an elegant Cocoa interface for fast, easy case entry.  You can also attach screenshots, and use an integrated status bar menu to browse the history of recently created cases.  Tickets even provides excellent features for power users, including support for Global Hotkeys and Applescript automation.

Tickets requires Mac OS X 10.6+, and is available for purchase on the Manicwave website.

We've just started sending out an email newsletter to Fog Creek customers who are interested in:

• Classic articles on software development and project management
• Release announcements concerning offerings from Fog Creek and its partners
• Helpful how-to guides for FogBugz and other Fog Creek products such as Kiln and StackExchange
  
• Links to new posts appearing on this blog
  

Sign up here: http://www.fogcreek.com/FogBugz/Newsletter.aspx

And check out the web-based copy of Issue #1 (sent out this week) right here: http://media.fogcreek.com/newsletter/2010/Newsletter1.html

Newsletters will go out roughly twice a month. Feel free to forward them along to friends and coworkers!

The FogBugz Team is pleased to invite another product into our partner ecosystem: SnapABug Visual Customer Support.

SnapABug allows website designers to quickly and easily embed a small (but powerful) "Help" widget in their site. When a user of the site experiences a problem and clicks the control, they're presented with a small form that gathers their email address, a short description of the problem, and (optionally) a screenshot of what they're seeing on the website.

Here's the best part: if you use FogBugz to track your customer issues (and honestly, why wouldn't you), you can configure SnapABug to automatically generate a FogBugz case that contains all the data entered into the SnapABug form, with screenshot attached.  It's never been so easy to run a responsive help desk for your customers: instead of spending valuable time determining the particulars of the problem, you can use SnapABug to quickly discover, reproduce and diagnose the bugs getting in the way of your users' happiness.

Learn more about SnapABug and start a free trial at http://www.snapabug.com/.

We've had a recent problem with potential and current customers finding old and outdated information on our discussion boards.  One option we had was to archive the discussion board each time we have a new release (probably the best idea), but we didn't do that unfortunately.  Our other option is to just erase all old topics from our database (not nice to Google and we don't want people to think we're hiding our warts). The third option is to leave the content up and figure out a way to really make sure people know the info they are about to see no longer applies to our current product (probably).  It took me about ten minutes to come up with a solution using the BugMonkey plugin, which allows you to insert arbitrary JavaScript and CSS into your FogBugz site.

You can see an example in this post about FogBugz 4.0.

You can view the code I used for the lightbox effect.

You can also download and view the javascript: sample.js (880.00 bytes)

In doing this I realized it would helpful if there was a systematic id system for text portions of the page (in this case, it was difficult for me to get the date of the topic, since I didn't want it to be applied to current topics). Definitely something to think about in the future...

FogBugz users who develop in the Eclipse IDE should have a serious look at Foglyn, an Eclipse plugin by Peter Štibraný that allows you to view, organize, and manipulate your FogBugz cases without ever leaving the IDE. 

Foglyn smartly builds upon the Mylyn task management interface to make it perfect for use with FogBugz:

• Easily run a search query returning a list of cases you care about, and view subcases in outline format
• Edit cases using a powerful form interface
• Embed hyperlinks to FogBugz cases directly in source code
• Easily tell FogBugz what cases you're working on by activating them right from the IDE

Eclipse users can visit www.foglyn.com to download the plugin and try it free for 45 days.

In this video, Dan and Babak talk about how we got to FogBugz 7. 

(Click to watch the large version on YouTube).

We recently launched the FogBugz Knowledge Exchange, a powerful Q&A resource for anyone who wants to learn, teach or discuss FogBugz.  It was (quickly and easily) built upon the Fog Creek StackExchange platform, and has been continuously gathering users and helpful content since the moment it hit the Interwebs.  It's no surprise to see that Support Lead Rich Armstrong is currently at the top of the reputation rankings, with FogBugz Development Ninja David Fullerton also strong out of the gate.

In the past week or so, we've taken the additional step of moving all FogBugz 7 Knowledge Base Content onto the Knowledge Exchange.  (Users of the original FogBugz Knowledge Base will be redirected there automatically when they navigate to an article pertaining to FogBugz 7.)  It may seem a bit odd at first to have a dude named "FogBugz KB" lurking around, asking and answering his own questions.  But now that the KB content is on a StackExchange site, the community will be able to collaboratively edit and improve answers, provide alternative answers, and spin off related questions that will gradually fill the gaps in our collective FogBugz knowledge.

So if you have a question about FogBugz, be sure to head over to fogbugz.stackexchange.com and see if it's already been asked and answered (The StackExchange platform offers a fast full-text search of all content.).  If not, don't be afraid to ask.  No question is too newbie, and no question will remain unanswered for long.

No, it's not a cable news station, it's a brand new FogBugz Plugin that gives you up-to-the-minute updates on your team's activity.

The FogBugz News Network (FNN) Plugin allows you to quickly view the most recent updates to cases in your FogBugz database.  You can choose to see everything that's happening on your FogBugz site, or filter by project and/or user to zero in on the cases you care about.

The Plugin also includes a "Work In Progress" report that shows which cases users are currently working on, including updated estimates and time remaining values for each.

You can download the Plugin form the FogBugz Plugin Gallery.  To learn more about FogBugz Plugin development, check out our "Features" page, the FogBugz Developers Wiki and the Plugin Ideas Forum.

The FogBugz Team is pleased to report that the Balsamiq Mockups Plugin is officially out of beta and available for purchase.  We're huge fans of Balsamiq Mockups, and find it to be the ultimate tool for fast, effective spec writing.  The new FogBugz Plugin cranks the awesomeness up to 11 by allowing users to embed active, editable mockups in FogBugz cases and wiki pages. 

You can download the Plugin on Balsamiq's product page, or find it in the FogBugz Plugin Gallery.

To learn more about FogBugz Plugin development, check out our "Features" page, the FogBugz Developers Wiki and the Plugin Ideas Forum.

In a previous article, I wrote about the FogBugz Plugin Architecture, and how it lets us answer some very common customer requests without suffering from feature bloat. In this article we'll examine in detail one of our most popular plugins, Workflow, which does just that.

The Default FogBugz Workflow and Why It's Good

Out of the box, FogBugz provides an intentionally simple workflow for cases. Each case passes through three stages: active, resolved, and closed. When a case is created it is assigned to someone as an active case. When the issue has been dealt with, it is resolved. At that point, it automatically goes back to the original opener so that they can verify the solution. Once they are satisfied, they close the case.

This workflow turns out to work very well for a variety of case types. Bugs start out at a tester or user who found the issue, then go to a developer who fixes it and then resolves it back to the opener for verification. Features begin at the person requesting the feature, go to a team lead or developer to implement, and then end up back at the person who opened it to confirms that the feature meets their requirements.

Furthermore, this workflow encourages a particular way of using FogBugz. It encourages users to verify the resolution of cases, which means more bugs are actually fixed. It also encourages a simple process, so a developer can open a "remember to write the documentation" case without it having to go through six steps of approval. This means that more cases make it into FogBugz instead of ending up as sticky notes all over the monitor.

The default FogBugz workflow: active, resolved, and closed

When the Default Workflow Isn't Enough

Unfortunately, there are some cases where the default workflow breaks down. Sometimes a customer will open a case to report a bug, but they really shouldn't be responsible for verifying it. Often there is a QA person who should be involved in the process for certain categories of bugs. Or a team might want to differentiate between a feature that still being specced and one that is in development.

The default Workflow is very much a 90% solution: it works great 90% of the time (probably more, actually), but that last 10% of the time it just doesn't do what you want. The result is that you end up fighting with the tool, rather than having the tool get out of your way and allow you to get your work done.

At the same time, the last thing we want is for an organization to get FogBugz and then spend a week in meetings drawing flowcharts trying to decide what happens if a bug gets found by a tester in Department A, but it actually comes from a component developed by Department C, so it needs to be verified by the QA teams in both and there's absolutely, positively no way anybody can start creating bugs until this is figured out.

We want FogBugz to JUST WORK, right up until the point where it doesn't, at which point you find the super easy solution we've prepared for you, click a few buttons, and continue on your merry way.

Customizing the FogBugz Workflow

Fortunately, plugins give us a great way to have both simple, sane out-of-the-box behavior, and powerful customization only a few clicks away. For users who don't care or who find that the default workflow is good enough for them, FogBugz continues to work exactly the same. But for the users who need the ability to customize their system, the Workflow plugin can be installed with just a few clicks from the FogBugz Plugin Gallery.

The Workflow plugin allows users to customize workflow in two ways: by defining new categories and statuses, and by specifying how cases are assigned when transitioning a case between statuses.

The Workflow plugin adds a new item to the Admin menu

Custom Categories and Statuses

The first thing to do when customizing the FogBugz workflow is decide what types of cases the customization should apply to. This isn't always as straightforward as it seems. It may seem obvious that all bugs should have to be verified by QA, until you actually implement it and your developers start complaining that every time they create a little case for themselves to remember to fix something it has to be verified by QA. Before you know it, they're back tracking their bugs in notepad and you're amazed at how effective your new process is at reducing the number of bug reports in your software.

Since changing the workflow is potentially so disruptive, we recommend trying out major changes on an entirely new category, which the Workflow plugin makes completely painless to create. In our example, we might create the category "Bug (Needs QA)". Now developers can continue to create reminder cases for themselves that don't have to go through QA, and testers can create cases that will always follow your new workflow. Later on, with just a few clicks you can delete the old "Bug" category if you find you're not using it.

Once you have your categories nailed down, you'll want to create some statuses for them. Here you can take advantage of another new feature in FogBugz 7: multiple active statuses. Before FogBugz 7, all categories only had one active status: "Active". Now using the Workflow plugin it's possible to add multiple active statuses. For example, you could create the "Active (In Development)" status for bugs, or the "Active (Needs Spec)" status for features.

For our example above, we'll add two resolved statuses: "Resolved (Fixed)" and "Resolved (Verified)". When the development team has finished fixing the bug, they resolve the case as "Fixed". When QA has finished verifying the case, they'll resolve it as "Verified".

Add a new category with just a few clicks

Customizing Case Assignment

The other half of custom workflow is defining how cases get assigned when changing the status. In FogBugz 7, each project can have its own workflow. This allows you, for example, to have a special workflow just for the "Inbox" project, or have one workflow shared between all development projects.

Each workflow determines to whom cases are assigned for each status in four different circumstances:

1. Creating or Editing the status of an active case
2. Reactivating a resolved case
3. Reopening a closed case
4. Resolving a case

When selecting to whom the case is assigned, you can choose either a particular user (e.g. "Joel Spolsky"), or you can choose a special value such as "Primary Contact" or "Case Opener", or even "No Change" to keep it assigned to the same user.

You can also choose whether the assignment is forced. Forced assignment means that when the workflow rule is in effect, the "Assign To" dropdown will not be editable. This guarantees that the case will be at least initially assigned to the specified user.

For our QA example, we'll set the rules for our statuses as follows:

When Resolving a Bug (Needs QA),

• Resolved (Fixed) assigns to "Alison Tirrell", our QA lead, and is forced
• Resolved (Verified) assigns to "Case Opener", and is forced

For everything else we'll use the defaults. This will give us the following workflow for cases opened as "Bug (Needs QA)":

1. Case Opened
2. Active & gets assigned to a developer
3. Resolved (Fixed) & gets assigned to QA by the developer
4. Resolved (Verified) & gets assigned to the case opener by QA
5. Closed by the case opener

Using this workflow, we've preserved the original spirit of the FogBugz workflow, where the opener verifies a case, and added a QA step for bugs that need it.

Determine to whom cases are assigned by editing the workflow

What Custom Workflow Isn't

As powerful as this method of custom workflow is, there are a few things that it can't do. It doesn't allow restricting the order that statuses have to go in, so there's no way to say that the "Active (Needs Spec)" status must progress to "Active (In Development)" before going to "Resolved (Implemented)".

It also doesn't allow restricting on users: there's no way to say that only an administrator can close a case, or that cases with the status "Active (In Development)" have to be assigned to a developer.

Also, having a "forced" assignment in the workflow only determines who the case is initially assigned to. Once the case is assigned to a user by a "force" rule, it can be reassigned to anyone (though the original user will always get a notification that the case was assigned to them).

In this, workflow follows the FogBugz philosophy of keep it simple, and stay out of the user's way. If a non-QA user really wants to resolve a case as "Verified", they probably have a good reason to do so. If a user needs to grab a case back after it has been assigned to the Primary Contact for review, they probably know what they are doing better than FogBugz does.

Advanced Custom Workflow

With that said, it is possible to build on the Workflow plugin to create more advanced workflows. If you want to make sure that cases with status "Active (In Development)" are assigned to a developer, you could make a plugin that automatically finds cases in violation of this and reassigns them to an appropriate user.

You could also use plugins to create special virtual users that your workflow assigns to, which have a special meaning in the plugin. For example, you could create a "Case Owner" plugin that adds a new "Case Owner" field to cases, and then lets you choose "Case Owner" as the person assigned to when a case is resolved. Or you could make a "Round Robin" virtual user, and have the plugin distribute incoming cases to one of several users, and use this to handle incoming support requests.

A plugin could even do a similar thing with statuses, by having a special "Next Step" or "Auto" status. When a case is set to the status "Next Step", the plugin takes over and moves it to the correct status and assigns it to the appropriate user.

These are just a few ideas of advanced workflow plugins that could be created. If you have your own idea, you could add it to the Plugin Ideas Forum, or get started writing your own, and of course we'll be happy to answer any questions you might have on our StackExchange site.

We decided to add subcases
Customers have wanted hierarchy in FogBugz for years.  They wanted to break their cases up into subcases and add to-do lists.  They like things to nest.  Lots of other bug trackers try to satisfy these demands, and a long time ago we decided to make this a high priority for our next release.

How hard could it be?
It should've been a simple task.  Add subcases to FogBugz 7.  Users need the ability to break down their cases hierarchically or create simple to-do lists inside of their bugs.  Most people could code it up in a few hours, or maybe a caffeine-hazed weekend, right?

So why did we wait until FogBugz 7 to do this if people have been asking after it for years?  As it turns out doing it right took some time...as we've gotten used to when building a new feature.

Doing it right - The first stab
Like most things that go into FogBugz, we're highly concerned with getting it right.  Our features need to be intuitive, simple to use.  If we add too much complexity we risk becoming just another arcane project management system requiring an advanced degree in Ganttonomics to operate effectively.  

On the other hand if we made subcases too simple we knew that the whole implementation would be disappointing to users. 

One early design we considered was to nerf subcases by not making them full FogBugz cases.  Users would create little subtasks that were essentially one-level-deep lists within their bugs.  Wallah!  Task lists.  We get to pat ourselves on the back and tick off another "feature" on the giant feature matrix.  But we quickly realized we'd run into all kinds of complaints: "Why can't I tag my subtasks?", or "I need to assign these tasks to someone else, and I can't!"  Before you know it you'd be waiting for the next version to come out with all its grand promises: "FogBugz 8 -- now you can finally add a due date to your subtasks!"  We've seen such missteps made by others when new features aren’t fully integrated into the core of the product, and we knew this option would never be a winner.

Doing it right - Round 2
After we rejected the nerfed subcase option, our program manager produced a slick spec.

It was a great start, so naturally we immediately started to argue.  Everyone wanted to make a fantastic feature, and everyone had different ideas about how to do that.  So we went round and round...and round.  We finally settled on a design and implemented an initial version.  We showed it off as an internal demo.  Surprise!  We needed more and more changes until everyone inside the company was happy with what we had.  Then we ran usability tests with a couple FogBugz customers.  Lo and behold, we discovered some major problems with our display of subcases in the grid view.  Sometimes when sorting and grouping in the grid view a case belongs in more than one grouping.  For example, a case may be assigned to me and show up under the "Assigned to Ben Kamens" group, but it also belongs directly under its parent case, which is "Assigned to Joel Spolsky".  In those instances we were simply displaying the same case twice in the grid view under both groupings.  This basically caused people's brains to melt.

Doing it right - Round 3
We had to redesign again.  After that last usability test, I was 100% positive that showing a case twice in the grid view was a terrible mistake.  Luckily, Dan, our FogBugz PM, wasn't so sure; he came up with an excellent set of affordances to make the duplicate cases much clearer and to give users the option to just show all cases (including subcases) in a flat view.  He was sure we could do it right and he went to work on me.

We went round and around about this again, as the case below demonstrates (and trust me, this is just a portion of the back-and-forth).  There’s a lot of passion about these issues at Fog Creek.

I was eventually persuaded that we could show duplicates if we were very careful about how the display worked.  The next round of feedback showed that this was right, and the two views we built in were a big success.

Other challenges
Subcases also presented a purely technical challenge: We needed to query hierarchical case structures without slowing down FogBugz.  More accurately, we had to run fast hierarchical SQL queries (get me the children of case 5, and their children, and their children, ... ) in all three of our supported databases: MSSQL, MySQL, and Access.  The support for recursive queries in these three databases is varied at best, and nonexistent in one.  Can you guess which is which?

Turns out there's a pretty cool solution for this problem explained by Joe Celko.  Instead of attempting to maintain a bunch of parent/child relationships all over your database -- which would necessitate recursive SQL queries to find all the descendents of a node -- we mark each case with a "left" and "right" value calculated by traversing the tree depth-first and counting as we go.  A node's "left" value is set whenever it is first seen during traversal, and the "right" value is set when walking back up the tree away from the node.  A picture probably makes more sense:

How does this help?  Now we just ask for all the cases with a "left" value between 2 and 9 to find all of the descendents of B in one fast, indexed query.  Ancestors of G are found by asking for nodes with "left" less than 6 (G's own "left") and "right" greater than 6.  Works in all databases.  Greatly increases performance -- particularly when querying large hierarchies.

What we delivered
Waiting to add this feature was worth it. Initial customer reactions have been very positive, and we've even had people who had no real interest in subcases when they heard it was coming tell us that it's changed the way they use FogBugz. 

• We added a context menu to the grid view which allows you to very quickly add all your subcases right there.  This makes it super easy to set up a whole set of tasks and break them up into their parts without leaving the grid.
• The outline view lets users easily see their cases’ hierarchical relationships.
  
  
• We clearly mark subcases that exist but do not match your current filter or search.
• We've added auto-complete to the case view so you can make existing cases into subcases of the one being currently viewed by simply typing a case number or searching for words in its title.
• You have the option to resolve and/or close all subcases when resolving the parent case.
• Subcases are fully integrated with search, filters, and all standard FogBugz workflow.
  

That's the feature we fought so hard over.  So far the feedback has been uniformly good, and we think it's a keystone in our best release yet.  You should try it out and sign up for a free FogBugz 7 trial.
 

One of the major features Joel mentioned in the official launch of FogBugz 7 was "Scrum support."  Distilled to its essence, Scrum is characterized by:

1. Short "Sprints" that produce "Product Iterations": Each "Sprint" lasts around 15-30 days, and a release cycle can contain one or many product iterations.
2. The "Product Backlog": For each project, a "Product Backlog" list is kept that's essentially a feature wish list sorted by priority. The features are sometimes represented as brief "stories," such as "Allow FogBugz users to create subcases," and each is assigned a rough work estimate. The features that are higher up the list are given more detailed analysis in terms of work estimates and are broken down into greater detail.
3. Daily "Scrums": Once the sprint starts, the team holds daily 15-minute meetings, in which each member of the team summarizes:
   What tasks he/she worked on yesterday
   What tasks he/she will work on today
   Any Issues that might limit his/her progress
4. Burn Down Chart: Sprint progress is tracked through the use of the "Burn Down Chart," which plots the overall estimated time remaining (in the sprint task list) against the date. The goal is to keep things on track for a zero time remaining by the end of the 15-30 day sprint.

FogBugz 6 – already Scrum friendly?

Many of our customers told us that FogBugz felt too heavy for them to use in their Scrum shop, and we weren’t exactly sure why.  "FogBugz supports all of these things," we thought.  A Fix For in FogBugz can be used for every sprint.  Just order things by priority, and bam! Average-sized backlog.  Daily scrums have no place in a online tool, since that is antithetical to a short, daily meeting that is really not meant to be recorded. And the burn down chart was just a way of reading EBS graphs with your head tilted to the side a little.

Nah. FogBugz 6 didn’t work well for Scrum

Creating a Fix-For in FogBugz 6 took 5 clicks, and then you still had to change the Fix For on all the cases that were going into the sprint.  That’s pretty heavy.  Release notes were only useful if you used 1 Fix For per release.  That’s not the way Scrum works; usually there are multiple sprints per release, so whoever was responsible for release notes would have to splice together the FogBugz release notes by hand.

Also, FogBugz priorities are too coarse-grained to be useful for a product backlog; the backlog should be a full ordering, not just a set of buckets where we say "well, these cases are all pretty important, but these over here? Mega important." And if you use it that way, once you move cases into the sprint backlog from the release backlog, you have to reprioritize them, since they’re all going to be in the top 1 or 2 priorities anyway.  It just didn’t work.

Another big mistake was thinking that the Completion Date Over Time graph in EBS was essentially just a burn down chart. We were correct, in a way: the data source for the graph was the same data one would use to make a burn down chart. But the two graphs are used for different purposes:

For a sprint, which tends to be short, the work schedule-agnostic burn down chart actually makes a lot of sense, for three reasons:

• It illustrates an absolute finishing point. The date of completion is asserted, not predicted. If the burn down line is not on track for completion, functionality is removed from implemented features.

• Sprinting team members are likely to violate their work schedule. An "all-out" mentality is often applied to the latter stages of a sprint, and teams are often given an extended breather between sprints.

• Team members are more likely to pick up each other's slack. The team maintains a sharp focus on achieving sprint goals, even if one team member's schedule serves as a roadblock. They are likely to adapt in an unpredictable fashion and take on each other's tasks as necessary.

In contrast, the existing EBS-predicted ship dates are superior for planning a larger release further down the road:

• It predicts a finishing point. For a full release cycle, you want to identify feature goals first, and then let EBS produce a set of reasonable dates.

• Huge values of "hours remaining" are cumbersome.

• Work schedules will average out over a long release cycle, even if they vary during a sprint.

• Team members will maintain ownership over specific features over the long run, even if tasks shift around a bit during a sprint.

We fixed FogBugz 7 for Scrum shops

The first thing we did was to lighten up Fix Fors.  We renamed them to "milestones," which lets them be used more generically. The release notes page was tuned up to let more than one milestone be part of the list of release notes. Finally, the biggest improvement to milestones was on the grid view, where you can now create a new milestone and move all selected cases into it using 2 clicks. Changing the milestone on some cases is even easier, using the same button.

Secondly, the Project Backlog plugin was created to map product backlogs into the FogBugz world view.  For each project in FogBugz, the plugin keeps a fully-ordered list of cases in the project, and lets users move them around within that ordering.  When your team has an idea, they put a case containing the user story into the backlog.  If that user story gets into a sprint from the top of the backlog, then it’s time to start adding subcases to flesh out the different parts of the bug fix or feature.

Finally, we added evidence-based burn down charts.  Using the EBS 2.0 algorithms, we can calculate 5%, 50%, and 95% envelopes for how many hours are remaining in a milestone.  With this innovation, we use your developers’ estimation histories as a predictor for their estimation accuracy, and we can give you more accurate burn down charts than simply accepting those estimates at face value.  The deadline for the sprint is clearly marked with a vertical line.  If it looks like the Hours Remaining will chug down to zero before the deadline, you’re fine.  If not, it’s time to start cutting features like the BLINK tag that should’ve been cut so many years ago.

Daniel Root has posted a walkthrough on how he uses FogBugz 7 and Scrum.

"Every day of the Sprint, a very short meeting is held where the each team member says what they did yesterday, what they will do next, and if there's anything holding them up. If something is holding them up, it's up to the Scrum Master to make sure the problem gets resolved. At the end of the Sprint, the Team has a working product that is shown to the customer in a Sprint Review and/or deployed into production. Feedback is received and items added to the product backlog, and the process repeats until the project is complete. I'm sure true Scrum Masters will balk at some of this - we typically combine what would be a Sprint Review and Sprint Retrospective, and are fairly informal with the process. We don't call the meetings or people by their official scrum names- in fact most of our customers don't even know we're doing this to them!" 

Read More...