However in the case that you're just starting with Scrum I would argue that you might be better off without tools. All tools force you into some kind of process that works for somebody else, but might not be optimal for you.

So instead of jumping to a fancy tool that comes with all the bells and whistles instantly, I'd recommend starting as low-tech as possible, learn the basics and discover your individual needs. After that you are enabled to get the Scrum tool that does exactly what you need it to do.

How do you start low-tech? Use pen and paper.

Experience over tools

Scrum as an agile methodology has a very shallow complexity. It doesn't require many artefacts in the forms of documents, lists, reports or charts.

The artefacts defined in Scrum are the Product Backlog, Sprint Backlog and a Sprint Burndown Chart. Personally I find two more "artefacts" to be extremely useful: User Story Cards and one set of Planning Poker Cards for each team member.

No more than three documents plus two helpers for all your project management needs. Sounds like thin ice? Believe me, I know how you feel but hear me out.

I started off doing Scrum in a waterfall environment, using tools that where developed for waterfall projects. It gave me the advantage of familiarity with the tools (false security?) but at the price of bad usability and cumbersome overhead.

Only since my ScrumMaster Certification I see the benefit of using low-tech "tools" like pen and paper. It is faster, more fun, breeds involvement and identification, can be distributed without permission and data security problems and most important: You will get a much better understanding how Scrum actually works.

Granted, the "high-tech" tools mandatory for my company are still in use, but I already wrote an article how to utilize SDLC tools best for Scrum so let's keep that aside for a moment.

Doing Scrum "hands-on" with pen and paper is easier than you might think. There are no complex metrics or calculations to perform. You will see that your planning meetings get a totally different dynamic if you work with a stack of user story cards and pen & paper. People interact physically with each other rather than staring at the pale image of the projector.

The Product Backlog

My product backlog template is as simple as it gets. One column with the user story number, to make identification easy. A title and a complexity column is all that is filled out in the beginning, usually by the product owner.

In the planning sessions the team will use its planning poker cards to agree upon a complexity which we fill out together in the second column to the right.

Last not least I added a column for dependencies. This will contain the user story number(s) that need to be completed before the one at hand can be filled out.

The User Story Cards

The title of a feature in the product backlog serves only as a short summary of the feature itself. It will not explain the task, only give it a name.

User stories fill that gap. My User Story Card template is half of an A-4 size paper, print it on a duplex printer (so that page 2 of the template is printed on the back) and cut it in half.

The head of the front page of the user story contains the user story number and the priority, both also found in the product backlog. Another header entry, the estimation is left empty. Here we will the required time (not points!) for the task, in the sprint planning meeting.

Note that I estimate the features in the product backlog in story points through planning poker, but the tasks of a sprint in hours. One user story is usually comprised of several tasks. The "estimation" value on the user story card is the sum of hours for all tasks of this story.

The main part of the front of the user story card is pretty much standard, it has to be filled with the role of the user ("as a ..."), a feature description ("I would like to ...") and the purpose of the feature ("in order to...").

For example "As a logged in user I would like to be able to edit and store my delivery address in order to have it pre filled in the shopping basket."

In short, the front of the card will give a good overview of a feature. The back contains additional notes and the acceptance criteria as given in the planning meeting.

The Planning Poker Cards

Planning poker is easy to perform but I find it notoriously difficult to describe. I will leave it to the ever helpful Wikipedia to give a good run-down of the process of planning poker.

I can provide you with a template to cut out your own set of Planning Poker Cards. Bring a stack of uncut prints to your next meeting along with a bunch of scissors and cut them out together. Play your first couples of rounds on non-critical features or even features that do not exist in reality.

The Sprint Backlog

In the sprint planning meeting I bring the product backlog along, which has the complexity column already filled out. It contains the complexity in terms of story points, derived through planning poker.

During sprint planning the team picks features from the product backlog that have the highest priority to the product owner. The priority is usually based on business value so it makes perfect sense to finish the most valuable features first.

The user story that belongs to a product backlog feature is read aloud and a discussion starts. Questions are raised and clarified. This continues for a couple of minutes until the feature is commonly understood. Then, the team breaks the feature down in smaller tasks, which are written into the sprint backlog.

The sprint backlog template once again contains the user story number to easily identify and group the tasks. The sprint backlog also contains a column for the name of the task and a whole lot of columns for numbers.

In the sprint planning session we discuss the overall complexity of each task of a feature and estimate an amount of time (in hours). This value is being written into the "Est." column, marking the initial estimation.

Note that some teams prefer to estimate both product backlog features and sprint backlog tasks in story points (planning poker) while others prefer to estimate both in time. You'll have to find out what works best for you.

The other columns marked "owner" and "1" to "15" are not filled out yet. During the sprint the team members will pick tasks for them to implement, and write their name into the "owner" column as soon as they do so.

Every evening before leaving the office the team members do a re-assessment how much time on their current task is left and write that into the column marking the Nth day of the sprint.

Let me say that again: The columns "1" to "15" contain the amount of time that is left. It is irrelevant how much time someone spent on a task. The criticality of a delay derives from too much work remaining.

The Sprint Burndown Chart

Finally there is the sprint burndown chart which will display the amount of work remaining on an every day basis.

At the end of the sprint planning meeting the sum of time in the "Est." column of the sprint backlog is transferred to the "day 0" column in the sprint burndown chart.

Note that the vertical axis doesn't have numbers assigned to it. Those vary wildly depending on team size, velocity and sprint length. Fill it out yourself.

During the sprint I will take the sprint backlog every morning and update the sum of time at it's bottom. This number is X'ed on the corresponding "day N" column of the burndown chart and the joining X's connected. Done before each daily scrum this is a good information radiator telling everybody how well the progress is without even talking about it.

It is a good idea to draw a line of "ideal progress" onto the burndown chart as well. This is a straight line, starting at the sum of values of the "Est." column in the sprint backlog, going straight to zero at the column of the last sprint day. This way you can easily real progress with ideal progress.

Conclusion

So there you are, a complete set of templates for your pen & paper based Scrum management needs. For your convenience I've also prepared a .zip file of all .pdfs that will also contain a set of Office 2000 compatible .doc and .xls files of the same templates.

Give it a try.

You can always come back to technical solutions or add a column here and there if you think you'll need them. The KISS principle applies. Keep it simple. I haven't really found a need for more columns in my projects yet. But your mileage may vary.