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.

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.

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.

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.