Goodness knows there are better sites than mine for learning about Scrum, a software development project management method. But, here's my two cents anyway. In other words, I'll give you some opinions along with the facts.

Scrum is an Agile method, meaning it attempts to apply Agile software development principles according to the Agile Manifesto. Scrum isn't mysterious. None of the Agile methods are mysterious. They're just ways of organizing and monitoring tasks. I'll bring this up again in a later post, but for now I'll just say that I like Scrum's organization quite a bit.

Any project has a desired end result, and a set of things to do to reach the result in a given amount of time. Scrum's efficacy comes from not fixing all the tasks up front. Instead, most of the things to do are changeable, except what's being worked on right now. Here are what I consider the basic Scrum terms.

Uncommited Backlog
The prioritized list of items to be completed in the future. Higher priority are at the top. These are usually larger features, not small tasks. They are estimated using Effort Units, which can be anything. The point of effort units is to show roughly how much relative effort an item will take. I'm using Ideal Days, which isn't exactly recommended. The Uncommitted Backlog isn't set in stone, but changes as the release product develops.

Sprint
A committed set of backlog items to complete in a fixed period of time. My sprints are two weeks long, but Scrum suggests a month. Backlog items are pulled from the top of the uncommitted list, and only as many as the team thinks they can accomplish in the sprint period. They then break down the items into tasks and give hours estimates to them.

Sprint Burndown
This chart shows how work is progressing on the sprint. It's a view of hours remaining, so you'll see the team "burning down" to zero.

Daily Standup Meeting
If you're in a team who work in the same place, this is an effective daily ritual. A standup meeting takes about fifteen minutes. The team members tell what they accomplished yesterday, what they'll accomplish today, and what's getting in their way. The Scrum Master notes impediments and works to remove them. This isn't a gripe session. There isn't time for that.

If you're a solo developer, like me, or if your team isn't in one location, you should still do some kind of daily meeting. In a project I'm working on, I try to email the other team member each morning about what I'm going to work on that day.

Tools
Many people use paper and/or spreadsheets to track sprints and backlogs. I've been using a free tool that is adequate for a single client/company, and is designed specifically for Scrum.
ScrumWorks Basic

I can't afford the professional product ($250/user, yikes!), but this tool is helping me on a couple of projects. I may end up writing something of my own that won't, unfortunately, be as fancy, but will better meet my needs.

Links
Here are Scrum links that I found useful. Especially helpful was the discussion of using non-duration Effort Units for uncommitted backlog items. My only grief with this approach is that it isn't management friendly. This is one reason I chose Ideal Days, so I don't have to translate something like story points or t-shirt sizes into an actual deadline. The people who sign my checks want to know "when is it going to be finished", not "how many dragon eggs are left."

Scrum Glossary
Planning vs. Committment Interesting, though I don't totally agree.
Feature Estimation Very helpful.

Here's a simple lexical analysis of Bill Gates' and Steve Jobs' latest keynote addresses.
Gates vs. Jobs: Keynote text analysis

What struck me is that Jobs is focused on the things, the devices themselves. Gates is focused on what can be done, the activities.

I'm inclined to favor Gates' mindset, but then again I don't think of computers as accessories.

Here's a good piece on healthy debating, from testing professional James Bach. It contains useful and practical techniques for many kinds of debate situation.

http://www.satisfice.com/blog/archives/111

Here are two articles about Apple's latest OS X operating system version, "Leopard". The first has some pretty strong complaints, the second is more complimentary.

http://www.pcmag.com/article2/0,2704,2223921,00.asp
http://www.pcmag.com/article2/0,2704,2207556,00.asp

What I appreciate about the first article is that he's moving back to Tiger because it's more stable and easier to use.

For the record, I don't use a Mac--yet--, and refuse to use Windows Vista. There's no good business reason to do so. My Windows XP installation is working fine, and I plan to buy my next computer before July so that I can get it with XP preinstalled, or just buy a copy of XP and wait on the computer.

Or maybe I'll finally move to Linux.

It turns out not to have been so difficult. Here's the CSS:

      
  #left_col {
    float: left;
    width: 250px;
  }
  #right_col {
    margin-left: 260px;
  }

The key is using "margin-left". I tried a bunch of other things, for instance positioning the right column relative to the left then setting its margin. All my other attempts lead to weird things like the right column's list items all being left aligned.

CSS is frustrating because I'll swear I'm doing something that makes sense according to the standard, but it doesn't work.

The biggest thing I learned--that's also fundamental, but I didn't know it--is that inline elements cannot have their width set. Only block elements can have a width.

So what do you do when you want a fixed width inline element? Set its display attribute to block and float it left.

Weird.