Hope you find them as useful as I do.

If you're irritated about what pen & paper Scrum is refer to the original article.

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.

He states that

There are now two definitions of Scrum. One is maintained and sustained by Jeff Sutherland and myself at www.scrum.org. Another is an old copy that is posted at www.scrumalliance.org, by the ScrumAlliance.

His article continues mentioning what sounds like the start of a copyright dispute over the Chinese version of the Scrum Guide (English version) which in its original form is written and maintained by Ken Schwaber and Jeff Sutherland. Apparently now the ScrumAlliance claims ownership to the Chinese translation of the Scrum Guide (again the English version). As Ken points out

Any of you familiar with copyright law know that a derivative of the original is still owned by the original copyright holder.

Ken Schwaber recommends

that you refer to the Scrum Guide created and sustained by
the authors of Scrum, Jeff and myself.

This is serious news.

Do we see the beginning of a split up of Scrum?

Well I don't know about that but the way I read the article we are seeing a split up between Ken Schwaber and Jeff Sutherland with the ScrumAlliance.

Already scrum.org, maintained by Ken Schwaber and Jeff Sutherland offers a Scrum Assessment program that looks similar to the one offered by the ScrumAlliance.

What good will come out of it?

Well again, I don't know. My personal opinion is "not so much".

I see Ken's point and his desire to keep his intellectual property his (and Jeff's).

I also agree with Ken that it is required to have one (!) formal description of what Scrum is. As he points out in application Scrum is mixed up with other agile approaches such as Kanban, XP and others. This makes it important to have one (!) "master copy" of what is Scrum and what is not Scrum. A benchmark is required.

Paul Oldfield of Capgemini may be right that in reality, in the scope of your project it does not matter whether your Scrum is 100% pure or whether you mix it with other methodologies in order to make it work for you.

The importance of a formal definition is on the global scale, not on project scale.

If Scrum minus Burndown Chart, plus 30% Kanban and estimations done through COCOMO works in your project, keep doing that! But don't call it Scrum.

There is only one definition for each of software design pattern. Differences in implementation in your project don't matter. But if I ask in a job interview what the "goal" of the Factory design pattern is and the answer is not something along the lines of "it deals with the problem of creating objects without specifying the exact class of object that will be created" ( (c) Wikipedia) the candidate fails. He doesn't know the Factory design pattern.

If you tell me your estimation method is PERT and the formular is "(opt + 3*real + pess) / 6" you are not using PERT. The estimation technique you're using might work perfectly well for you but it is not PERT.

Same for Scrum. The importance of one formal definition lies in what you know and what everybody (!) agrees to, not in what you do.

We need one formal definition

We are able to benchmark people against a principle only if there is one commonly agreed upon definition.

If there are several definitions of one principle the whole idea gets diluted and harder to assess. The principle in itself might - but doesn't have to - become less important.

I have no background information on what lead to the confusion as Ken calls it. But surely I hope that all involved parties get back on one table and keep Scrum unique. Keep it simple. Don't dilute it.

In this second part I will focus more on the virtual environment, the tools typically used by a company following the traditional waterfall approach / SDLC and how you might still be able to use these tools for Scrum.

Bug tracking system

Let me start with the bug tracking system. Most likely your organization will have one of those. Typically issues can be categorized, prioritized and assigned to a person as well as tagged or grouped into releases. To make this tool work for you in a more agile way you could create a couple of additional categories and put everything (!) into that system: Don't put only issues into it. Also add things like feature requests, enhancements, documentation, testing and refactoring tasks. I'm sure you can come up with more with a bit of thinking. Just be careful not to make this more complicated than required...

Well, that looks pretty much like a product backlog to me. You can do a printout of the overview and pin that to the board for better clarity. Stick it to the window with Scotch Tape if you don't have a pin board. In any case you should make this virtual backlog physical, otherwise the transparency will suffer. Only with a physical product backlog the team will have a clear idea about the big picture.

The overhead to maintain that printout would be minimal. You effectively avoid having two independent lists (in my experience always a recipe for disaster) and your not-so-agile management will probably be pleasantly surprised by the transparency you introduce.

Time tracking system

Next on my list is time tracking software. You know, that thing where you book how much time you spend on each project and / or task.

Well, there are two major ways to handle these in an agile way.

First, you (or the project manager) can create one bookable item in the tracking software for each of the tasks in the sprint. That'd mean one bookable item for each issue in the Bug tracking system (see above).

The benefit of this approach comes with reports - if that time tracking software allows custom reports based on Excel or similar, you can create a sprint burndown chart quite easily. Each item has a planned amount of effort (from Sprint planning) and the actual effort booked by all team members. That's all you need for a burndown. Calculate the sum of each and have Excel calculate a bar chart for each day - the sum of the planned efforts minus daily booked time is the sum of currently remaining efforts... at least until a task is re-evaluated. In this case you'd have to change your estimation.

The downside of this approach I'd say is efficiency. Depending on how userfriendy the interface is, tracking the time as a member of the agile team in a halfway precise manner can take quite a bit of time. Time better spent elsewhere. However, your company might demand such fine grained tracking. In that case it is best to get the most of it and get the burndown chart out of it as well.

The other way to handle this is on the other extreme of the bandwidth. Create one single task for the project and have all members of the team book all times onto that. They will love you. Higher management however may not, so use this with care. If you decide to go with this, you should encourage the team members to update the story cards with the current estimations, to keep track of where you are in the sprint and to generate the sprint burndown chart manually.

As always, the truth probably is somewhere in between. You could create one task for each type of work, i.e. one each for coding, testing, documentation, technical design, ... This will give much more clarity without too much overhead.

Conclusion

Your mileage may vary. The ideas presented here work for me, in the company I work, with the expectations that my management has. This may or may not hold true for you, and in your environment.

Let me know how you handle these situations! Use the comments!

Go and read the thread for quite a few interesting points. In a nutshell though, the question was how Scrum can help in fixed price contracts. I think that's an interesting question since at first sight a fixed price environment - and hence a fixed time environment - is contradictory to the agility that Scrum offers in terms of rescheduling tasks that have not begun yet, replacing items with others etc.

The consensus in the Yahoo group seems to be that fixed price contracts generally are a bad idea, will fail and that Scrum will not help you with that other than in damage control.

Well, in part I agree to that. Fixed price environments are tricky. Maybe they come into place because the client does not trust the agency, maybe it is a new relationship. Maybe they come to be because the sales staff of the agency gives the wrong impression in the first talks and no one dares to tell the inconvenient truth to the client after that, before the contract is written.

Maybe it is just how it always has been and we've all grown used to the process and the suffering involved?

I agree that some clients are politically important, door openers, key players. Whatever you call them, you will want a contract with them. Not for the sake of that contract but because of the things you believe you can get after that first contract runs well. And yes, in that situation it might not be very important to make profit on the initial contract.

But let's muse a bit on that thought. What good is a disappointed door opener client?

What I often see happening in fixed price contracts is that the agency over promises (too many features for too little money/time). With that being the base line the developer team is forced to deliver more functionality per day than they can deliver in good quality. Due to time restrictions, development becomes sloppy. Bugs creep in, further delaying the progress. In the end the developers are exhausted, the project manager has a hard time convincing the client that 'everything is still going really well' and the client senses that something is off. In the end he is presented a system that is riddled with bugs and sub-standard usability, and with reduced or missing features.

What happens next is usually a free-of-charge bug fixing period. In the meanwhile new requirements come in, which again tend to be priced below what the actual effort is. To make the client happy, after the initial disappointment. This vicious cycle repeats.

So in the end, don't we have a project in debt and an unhappy client? Did the agency really impress that client? Will he play the door opener role that management had hoped for?

So what might be the solution to that? What role might Scrum play?

Well I think the solution is trust. If the client is convinced that you're not stealing from him he probable is willing to agree to a more flexible approach.

So deliver early, deliver often. The sooner the client sees what you are doing, the earlier he will trust you.

Make sure that the client understands the MoSCoW method and that his feature list has a lot of 'should' and 'could' items. Deliver the most important features - those with the highest business value for him - first.

That way, even if progress gets delayed, the most important features will be done, and in perfect quality.

Ensure that the client spends a significant amount of time checking the interim states on the staging environment. You will need his feedback early. As Pete Deemer explains it, bugs are like tigers: At first they're little cute babies but if left unattended they become man eaters hiding in a thick jungle, waiting for the kill. So better to take care of them early on, and don't let them enter the thick undergrowth of your project where they will hide and grow.

I believe to some extend this picture applies for features in general: Only the client knows what he really wants. So the sooner you show him a working part of what you think he wants, the faster he can correct you, while the gap is still small and easy to bridge.

Bottom line

Being honest with the client is not the easiest approach. He might be irritated when two people from the same company (Sales, Project Manager/ScrumMaster/...) tell him two different things.

Management in your own company may not approve this seemingly radical paradigm change. Make sure you introduce it gradually.

Not all clients may be willing to work in an agile way.

So there is no silver bullet. There is no single solution that works every single time.

But I'm convinced that with open communication (think: full disclosure) and early delivery, Scrum can do a lot in damage control. Fixed price contract or not.

The good thing about the standard Indian IT office is that it is built from cubicles. That way people can quickly shift from one cubicle to the other to form a team that sits next to each other.

The bad thing about the standard Indian IT office is that it is built from cubicles.

There simply is no space for big white boards or task boards to tack all the user stories on.

But no one prevents you to use pen and paper. If your software design doesn't fit on an A-4 paper it might be too complex to begin with or more detailed than required. Tasks are not bigger than a few days of work, right?

It may not be feasible to put all user stories on a task board, but every developer sure can put his tasks on a wall of his cubicle. Our new office luckily has a small section of each cubicle wall converted into a mini white board. Cool stuff for rough sketches also but frankly speaking I wouldn't count on the sketch being there the next morning after the cleaning staff went through (knock on wood though, so far it worked).

Conference rooms - that mystical land where the white boards are - are rare and frequently occupied, so spontaneous meetings in there are somewhat impractical. However, with the office shift I secured myself and the teams two windows. Who says we can't draw sketches on the window? Word of advice though: Verify that your white board markers are removable on glass first! Any corner usually hidden behind blinds should do. Oh and those sketches will definitely not survive the cleaning staff. Make sure one of you has a decent camera on his phone .

The burndown chart in my case is easily printable on A-4 paper so it will literally fit anywhere. Starting from tomorrow it will be tacked right next to the window in question.