In this article I will present my current tool set of choice for the iPhone.

Word processor and spreadsheets

Quickoffice (iTunes) is pretty much what is claims to be. You get a Word editor and a spreadsheet application. Both natively work with Microsoft Office formats (old and new) and that is all I need.

The user interface for both applications is easy to learn and while the lack of keyboard and mouse does slow you down when editing spreadsheets, the app makes good use of gestures and multiple-tap events.

What I found to be missing however is the possibility to set headlines and other formats. Note that they are displayed and preserved correctly. You simply can't add new ones. The usual text decorations like bold, italic and the like work smoothly though.

You can up and download documents through a WebDAV interface. The MobileMe iDisk online storage is also supported but that isn't for me - I value the privacy of my data.

Strangely there doesn't seem to be a straight forward way to copy a file. You have to open the original, make a subtle change and 'save as...'.

Overall Quickoffice let's me get my work done and does it in a rather effective manner, for an ok price.

Aside from the 'pure' office functionalities Quickoffice supports a number of other file formats including images and .pdf, for which it provides readers/viewers. While rounding things up nicely, these readers lack some of the oomph that the Files app provides, see below.

Mind mapping

I can't exist without mindmaps. To me they are the organizing and structuring tool of choice. On the computer I use Freemind, because it is open source and it's many keyboard shortcuts make creating and editing a mindmap really fast.

There are many mindmapping tools for the iPhone but I believe iThoughts (iTunes) is a clear winner here. It supports virtually all major mindmapping formats and makes clever use of drag and drop on the iPhone. Nodes can be individually styled and highlighted with icons - important for me for additional grouping and priorisation.

Once again, files can be up and downloaded through a WebDAV Interface or through an online storage service, in this case box.net.

Same as above, mobile storage doesn't work for me and I believe it shouldn't be an option for any business use. Your data simply isn't save.

Generic file storage

The Files application (iTunes) is a WebDAV accessible storage medium on your iPhone. Think of it as a WiFi stick.

You can set up a quota how much space on the device Files can take up and security is provided through an access password.

Note: It can savely be assumed that the content of the storage remains unencrypted, the password most likely serves only as access prevention.

What I like about Files is that it supports reader functionality for most common formats, including .pdf, office formats and an image viewer much like the Photo application from Apple.

Offline bookmarks

Instapaper.com provides you with a simple service: You can bookmark websites to read them later, categorize them, tag them, you name it.

What makes Instapaper stick out of their competition is the good integration. Granted, a browser bookmarklet is nothing special anymore, neither is an iPhone app. Make the iPhone app (iTunes) communicate with one of the most frequently used Twitter clients (Twitteriffic) and make that communication both ways and you have created a huge amount of added usability right there. This is what Instapaper did. Tweet your latest finds right from the Instapaper app. Push articles from the people you follow into your Instapaper list without changing the app.

This is what I do - each morning during breakfast I add all potentially interesting links from Twitter to Instapaper, update the archive in the Instapaper app and I'm ready to go, able to read those articles whenever I want and indepepdent of network availability.

Summary

With Quickoffice, iThoughts and Files, there are three applications that bring their own storage logic and their own WebDAV interface.

It would be great if Quickoffice and iThoughts could team up with the guys from OliveToast (creators of the Files app) to utilize their storage for easier maintenance.

A very similar cooperation is already in place between Amidio and Intua, both creators of top notch music creation and sequencing applications for the iPhone. You can record a sample in one app, i.e. Hexatone or Noise.io, then fire up Beatmaker and load that sample through a common storage to sequence it with other samples. Recently that was simplyfied even further: Now you can copy-paste samples between the apps using the iPhone copy-paste logic.

Doing this for the office apps would greatly increase productivity.

Please note that the bits and pieces of information come from various sources and things may or may not be exactly as we think they are.

In order to understand what HipHop for PHP does it is important to understand how PHP itself gets executed. In this article I will give a rough overview of the PHP execution process and make a few educated guesses in what aspect HipHop for PHP differs from there.

Based on the little information available online I'll discuss how HipHop for PHP is suitable for large businesses and what might turn out to be obstacles that are yet to remove.

The PHP execution process

PHP code can not be executed directly, a property it shares with all other scripting languages such as Python, Ruby and JavaScript. What makes PHP executable is the Zend Engine, and it does so in a two stage process.

1. The scripts are parsed and analyzed, checked for syntactical and semantical errors and if all goes well the application is transformed into byte code.
2. Since the byte code is still not executable on a CPU, it is interpreted further into machine code (that is CPU dependent) and then executed.

For most PHP applications the first parsing stage takes most of the total time. The second execution stage is comparatively fast. So in order to speed up a PHP application, most code optimizers hook into the Zend Engine after the first stage has been completed and save the generated byte code into a cache. In a consecutive call to the webserver the cache will be fed back into the Zend Engine, thus skipping the entire first stage of the execution process.

There are quite a few products on the market that behave in such a way. Zend itself offers the Zend Optimizer (now part of Zend Guard), there is eaccelerator and APC, which comes as a PECL package.

The execution process with HipHop for PHP

What sets HipHop for PHP apart from these three (and no doubt other) accelerators is that it does not act as a cache. Instead, HipHop for PHP will transform your PHP application into C++ code and compile that directly into a binary which is executable.

In that sense, HipHop for PHP is probably very similar to Roadsend PHP which also generates executable code from PHP, albeit not by transforming it into C++ first.

In essence, HipHop for PHP will get rid not only of the first stage of the usual execution stage, but also of a big part of the second stage, namely the interpretation of byte code into machine code. Generally I believe it is safe to assume that HipHop for PHP has the potential to run an application much faster than any of the previously mentioned accelerators, simply because there is less for to be done at runtime. Time will tell.

For detailed information on the internals of HipHop for PHP make sure you watch the Facebook Technology Tasting video on ustream.

Possible limitations

The requirements
The requirements to run HipHop for PHP are available online. Nothing out of the ordinary at first sight. The page claims that HipHop for PHP is tested on CentOS and Fedora. Both are venerable distributions, no doubt. But both also come without vendor support which may or may not be a problem for your organization.

Granted, companies who's codebase can actually benefit from HipHop for PHP will no doubt have a team of excellent system administrators which maintain Linux in their sleep. But those companies might also be in the situation that their customers demand a Linux distribution with commercial support, such as SLES, RedHat etc.

So this is more an organizational issue rather than a technical. That being said it is not clear yet whether or not packages will be released by other Linux distribution vendors once HipHop for PHP is out. If at all, it probably won't happen soon.

Coming back to the requirements for HipHop for PHP, it requires customized packages of libcurl and libevent, which again may or may not be an issue for your environment. Here I see the same organizational issue, but also a possible technical issue - you might be in the situation that you need the original libcurl or libevent for some other software on the server. Only a practical test will tell.

Unsupported language constructs
As with most PHP caches and compilers, a few PHP language constructs are not supported. Most commonly known is the eval() construct which is simply not available in C++. Personally I believe that eval() is a bad thing to begin with and you can get around it in almost every cases. Sadly many PHP frameworks such as TYPO3, many PEAR packages, Drupal and Joomla make use of eval().

If you're intending to run one of these through HipHop for PHP you might need to wait for an update from the community, patch it yourself, or remove the code from the system if you don't need it. In any case this is a time consuming task.

Aside from eval() a few more language constructs may not be supported or may not benefit from the compilation in terms of performance, such as call_user_func_array() and other 'dynamic' constructs like dynamic variables, dynamic includes or built-in functions like function_exists(), class_exists(), get_declared_classes() etc.

HipHop for PHP is no different from other caches and compilers in these regards, so please don't make that affect your choice. Just be aware that things might not be as easy as you'd like them to be.

No Apache?
This is speculative at this point but the Running HipHop page on GitHub seems to indicate that HipHop for PHP will not make use of the Apache webserver but instead come with its own webserver. My assumption is that this means we'll have to handle HipHop for PHP through Apache, much in the same way that we frequently do with Tomcat. This is not necessarily an issue.

The potential of HipHop for PHP

Despite the limitations I mentioned above, I believe HipHop for PHP has the potential to take PHP much further into the enterprise environment than many of the existing solutions. If it can deliver what it promises it is definitely something we will take a very close look at to give our eCommerce framework a serious performance boost.

Very high on my wishlist is to run the transformation process from PHP to C++ but skip the compilation. If that's possible I see the chance to make debugging compile errors much easier.

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.

When you leave your comment on this blog you will be asked to type in two words which are displayed as distorted graphic. Most bulletin boards and free mail providers ask you to do the same before they allow you to create an account.

CAPTCHA 101

The reason behind is the same most of the time: Preventing SPAM. Spammers use forums, blog comments and contact forms to post their ads. They use bots (quite similar to the bots that update the search index on Google, Yahoo and all other search websites) to automate that process.

So the idea of CAPTCHAs is to present a task to a website visitor that is difficult to solve for a machine, but easy to solve for a human. The graphical CAPTCHA is the most commonly used one.

There are other CAPTCHA variants such as audio-based ones or image recognition based CAPTCHAs. I've even seen a simple math question as CAPTCHA.

The arms race

In December 2009 Jonathan Wilkins announced that Googles' most prevalent CAPTCHA method, reCAPTCHA has been broken. It is now possible to identify the words presented by reCAPTCHA with an accuracy of around 20%. For spammers that is good enough. WIth a 20% sucess rate, every fifth attempt will result in a successfully placed ad. Mr. Wilkins argues that even a success rate of 1% is good enough since the resources used by spammers often are not their own, thus their utilization is free (think bot nets).

This is bad news for everyone. I really hope Google updates its reCAPCTHA algorithm to a variant that is harder to solve by machines. For the record, I also use reCAPTCHA here in this blog.

Update: As of December 31st 2009 reCAPTCHA seems to be updated. Google responded quite quickly. So far I can already say that the number of spam posts I get in this blog has reduced drastically, albeit not come to a stop. Anyways, thanks for a quick response Google!

This situation is critical because spammers do not need to be particularly good at breaking CAPTCHAs. If one out of five CAPTCHAs can be broken and spammers still make a living out of this the CAPTCHA itself is useless in the sense that SPAM will enter your system.

Jonathan Wilkins has a .pdf paper where he gives guidelines for the creation of strong CAPTCHAs. It is a really interesting read even if you're not involved with CAPTCHA development  directly.

Which is the best solution?

Well I guess your mileage may vary.

For now I will stick to reCAPTCHA [official homepage] although it is broken and I need to remove a few unapproved comments every day. I like the idea behind the project so I'm willing to accept the minor annoyance that it currently imposes.

Text-recognition CAPTCHAs such as reCAPTCHA require strong OCR solutions and to my personal surprise, that is still a field what needs a lot of improvements. So even if reCAPTCHA becomes to cumbersome for me, I'll stick to another visual CAPTCHA method.

Audio CAPTCHAs are not recommended by Jonathan Wilkins because he argues that the field of speech regognition is more advanced than that of OCR. Aside from their security, I don't want my visitors to do something unfamiliar, and listening to an audio file to fill out a form certainly is.

I like the idea of asking a simple question, such as "What color is an orange?" or "What is 3+5?". Not sure about the security though. The latter one can be automatically solved by Google itself for example. However, I'm half way convinced that this is an approach that has a bright future.

Promising examples of what might be next

SQUIGL-PIX
On the reCAPTCHA website you can find a link to the SQUIGL-PIX project, apparently the latest project by the reCAPTCHA guys. It presents you with three images and asks you to outline a certain object. Only if you outline the object correctly (after chosing the correct image) the CAPTCHA is solved.

Give it a try. It is fun, easy (for us) and I sure hope it is hard for machines.

CAPTCHA The Dog
Another interesting approach is Captcha The Dog. You are presented with nine images total and have to pick the one that shows a dog while all others show a cat. You have to pick the single dog several times (from different picture sets) and click 'ok' once there are only cats.

The idea is brilliant and the basic reasoning behind it is the same that makes SQUIGL-PIX good: Object recognition instead of text recognition.

Captcha The Dog goes one step further and allows you to use your own set of images, tapping on the financial feasibility to break your individual set of images. There is even a Wordpress plugin available but I have to give a warning: According to the installation page the plugin requires allow_url_fopen and allow_url_include both to be active. Sounds like trading one evil for another. XSS anyone? Too bad, the idea is great.

3D image rotation
The third approach I'd like to present is proposed by Taylor Hayward and apparently does not have a name. It asks you to identify an object appearing in two rotated 3d renders. You are presented with one control image, and a set of nine randomly rotated images out of which one is the (rotated) control image. I found it hard to imagine so go see the blog - it'll be much more clear.

Once again, the method relies on object recognition. Great idea.

"Do not try this at home"

When you google for "php captcha library" you find literally thousands of home grown 'solutions' for secure CAPTCHAs. Once again I can only urge you to read Jonathan Wilkins paper on secure CAPTCHAs before you use one of them. The bottom line probably is that they will not work very well for you because their authors try to obfuscate the letters in a way that poses no or only very limited issues to OCR software.

Just assume that if Googles' solution to CAPTCHA is broken, yours will get broken too once the incentives to try are high enough for the bad guys.

That being said, developing your own approach while sticking to Jonathans guidelines will most likely be an interesting spare time project.

Possible benefits

Believe it or not, I really see possible benefits coming out of this arms race. As the spammers' tactics to solve CAPTCHAs improve, the good guys are forced to improve their generation of CAPTCHAs. After some time, the newer CAPTCHAs will also be broken. The cycle continues.

Naturally, the only way for the good guys to verify that the new version of a CAPTCHA is indeed more secure than the old is to think like a bad guy and try to break your own CAPTCHAs.

This might - and I believe it surely will - lead to better OCR software, better audio recognition and in general a higher standard in 'intelligent' algorithms that are able to solve every day problems.

Audio recognition might help the deaf to read what people say, by other means than lip reading. A universal translator (famous in Star Trek) is not completely out of scope either, although it is still really far away.

Text-recognition is highly in demand on mobile devices. If a program can identify highly distorted characters from a CAPTCHA, I'm sure the same ideas can be applied to read hand writing.

I will compare PERT and COCOMO, both being traditional techniques with a long history and Planning Poker, probably the most prevalent agile estimation technique.

All techniques have their pros and cons and it will be up to you to determine which technique will work best in your environment.

My comparison is purely based on experience, which is broader for PERT and more narrow for COCOMO and to some extend Planning Poker. Your mileage may vary. This article does not intend to be the definite guide on estimation techniques.

That being said, let's start shall we?

PERT

The PERT estimation is the standard estimation technique at my company. It is time-based and probability-based. The basic formula is to estimate an optimistic time (Topt), realistic time (Treal) and pessimistic time (Tpess) for an activity and generate a mean value (Tm) based on the formula Tm = (Topt + 4 * Treal + Tpess) / 6.

The realistic time Treal is weighted four times higher than the optimum time and worst case time, the sum of all three is divided by six.

For example if a task might complete in two days if everything runs fine, in three days under normal conditions and in five days if we run into complications the PERT value would be (2 + 4*3 + 5) / 6 ~= 3.2 days.

If you estimate all tasks of a project with PERT you can generate the variance and get a buffer value out of it which can be pretty handy. Don't trust that buffer blindly though.

One of the pros for me is that PERT acknowledges the fact that humans are particularly bad in estimating a task down to a single number. The thought of optimistic, realistic and pessimistic cases alone works wonders in discussions. The formula usually does a decent job to come up with a mean value.

Also a pro for PERT is that it is reasonably fast. Estimating a 3 month project on a level of abstraction needed for an offer usually takes no longer than a couple of hours.

My biggest con against PERT is that it is easy to misuse it. What I see frequently is that a discussion starts whether or not a particular task has a risk. Often that leads to optimum and realistic estimation being the same, let's say 2-2-5 instead of 2-3-5 as shown above. Or in a similar manner, realistic and pessimistic estimation are the same: 2-3-3.

Instead of the above mentioned 3.2 days for 2-3-5 we get 2.5 days for 2-2-3 and 2.8 days for 2-3-3. In a nutshell that ruins your buffer. You do not want that.

Another more general issue I have is that PERT is time-based but I'll get to that in a bit.

COCOMO

For me COCOMO is the rocket science approach for estimations. It is complexity-based and rooted on calibration through historic data. The algorithm behind COCOMO will get fine tuned over time, while your "database" of historic data grows.

The key figure in COCOMO is the lines of code (LOC or SLOC), more frequently thousand lines of code (KSLOC). You need to know - or in the first project, estimate - how long it takes to produce 1000 lines of functional code. Analysis, design, coding, testing, ... included.

Then you need to do an estimation of how many lines of code will have to be written or changed for the new project.

A set of factors or "cost drivers" such as project complexity, required quality, team experience etc. is applied to the estimations and after putting all this into a formula you get the estimated amount of time.

By far my biggest issue with COCOMO is that it is slow and too complex. You can't get decent estimation quality with COCOMO in a short manner of time. Even intermediate COCOMO takes into account no less than fifteen cost drivers, all of which affect each and every task. The bottomline is that you need a tool for estimating.

Disclaimer: There is a variant of COCOMO that is faster than traditional COCOMO. Personally I don't find that to be very exact, though and hence not very useful.

The second con against COCOMO is that it is fragile. Change your team constellation from one team to another and your historic data is useless. The same applies more or less for all other cost drivers.

I like the idea that COCOMO gets calibrated with time through your historic estimations. But in the reality of changing teams, hardly comparable projects and time pressure that leads to historic data not being available in a clean form frankly I never saw that work. Granted, that is not a failure of COCOMO but rather the methodology not working for us.

What I generally like in COCOMO is that it is complexity-based rather than time-based.

Planning Poker

Planning poker is an agile estimation technique. As the name implies it is based on playing cards (my .pdf for download) . The estimations in planning poker are relative, complexity-based and consensus-oriented.

Each planning poker card will show a number: "0.5-1-2-3-5-8-13-20-40-100-?-infinity" are a common set but there are other variations. The card "?" indicates that the estimating person can't estimate the task and "infinity" translates into "really, really huge" and can be seen as a sign that the task should be broken down into several smaller tasks.

The estimation works as follows: Each team member has a set of cards on his own. A task is explained, usually by the product owner / customer. A discussion takes place to clarify doubts from the team. After the task is clear, each team member picks a card out of his stack secretly and in unison they show the cards to each other.

If the numbers on each team members' card are reasonably close together (i.e. 8-13-8-8-5-13) a rough mean value is "calculated" (probably 8 in this case) and the next task comes up for estimation.

In case the numbers vary wildly the team members with the lowest and highest numbers explain why they picked their number. This is to reveal misunderstandings and generate a broader understanding for all team members. After that a second estimation round is performed. The process repeats until all numbers are reasonably close.

By now you may ask what the numbers are indicating? They do not indicate time. The card "5" does not mean "five days" or "five hours". The cards indicate complexity. There is no unit for the numbers, they are commonly referred to as story points or points for short.

What points show is that a task with a complexity of 2 is twice as complex as a task with 1 point and roughly half as complex as a 5 point task.

When estimating with planning poker it is absolutely mandatory to understand that each tasks complexity is only relative to another task. So what you do is you pick a comparable task that has already been developed (from your last project or the last sprint in the current project) and assign a medium sized number to it, for example "eight". Now for the current bunch of tasks you ask your team to compare the new task to that one and pick a card from their stack based on its relative size.

What you get is a consensus-based estimation how big or small a current task is related to one that is well known and understood. Since a task with complexity "eight" is almost twice as big as complexity "five", and you know how much time "eight" took to plan, develop, document and test, you have a rough idea how long the new task with complexity "five" will take.

My biggest pro for Planning Poker is that it will enable your team to estimate their own work. Usually this will take a few iterations as they need to get to know their own pitfalls but the long term benefits clearly outweigh the initial pains. Once the team knows how to estimate, you will not find anyone outside the team who can estimate the teams own work.

Another big pro for Planning Poker is that it is by far the fastest approach and that it is fun. Calculating numbers for hours and hours is boring, planning poker is more of a focused discussion.

One negative aspect of Planning Poker is that it is somewhat fragile. If your team size changes often, getting good estimations out of Pllanning Poker might be hard. But in agile the team constellation should stay constant even more than in traditional methodologies.

Bottomline

That's it, the three estimation techniques I'm most familiar with.

If you work in a traditional environment, give PERT a try. Use COCOMO if you can afford the overhead and if you have comparable projects in a very stable environment.

In any case I urge you to try out Planning Poker. While the methodology itself is agile, I don't see why Planning Poker should not work for you, even if you're in a traditional waterfall of SDLC environment. It will give your team a much better understanding of the upcoming work and enable it to participate in a project at a much earlier stage than usual. Through that, the team will feel involved and motivation will go up.

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.

I'm glad you like the topics and ideas I present here. I'll continue to give my very best in 2010 and I promise I have a couple of interesting topics already piled up.

A successful and prosperous year of 2010 to all of you!

Consider the following scenario: You have a group of classes, each responsible for returning a specific statistic. All these classes implement the same API, as given by a common abstract class.

Now, some of these statistics are publicly accessible, others require a certain access control permission to be set.

The logical approach would be to implement a static property to the abstract class, denying access by default. Those classes that are indeed public will overwrite the static property with the correct setting and become accessible.

The property is static to gain speed: There is no need to instantiate the class, if the access control is not satisfied.

Stripped down to the bare essentials the whole set of classes to outline the issue looks like this:

abstract class StatisticBase {
    public static $acl = '0';
} // end: class StatisticBase

class PublicStatistic extends StatisticBase {
    public static $acl = '1';
} // end: class StatisticBase

class AdminStatistic extends StatisticBase {
    // default value for $acl is fine
} // end: class AdminStatistic

AdminStatistic is an implemented class that is private, indicated by the $acl property being 0. PublicStatistic on the other hand is public, hence $acl is 1.

Now before instantiating a specific class we can check whether or not the access condition is satisfied:

if ($user->isAdmin == true || PublicStatistic::$acl == 1) {
    // retrieve admin statistic...
} // end: if

But naturally this is cumbersome as soon as you have more than a handful of statistics - you don't want to add another condition to your if-statement whenever you add a statistic. So the logical solution is a loop:

$statistics = array(
    'PublicStatistic',
    'AdminStatistic'
);

foreach ($statistics as $statClassName) {

    if ($user->acl == 1 || $statClassName::$acl == 0) {
        // retrieve current statistic...
    } // end: if
} // end: foreach

Here PHP 5.2 will fail with a fatal error.

You can't access static class properties by means of using a variable for the classname. PHP 5.3 can. There is no really elegant solution for this. (If you know one, post it in the comments!)

While I'm glad that PHP 5.3 has one more OOP feature covered, It leaves me with the feeling that we still have a long way to go until PHP fully supports object orientation.

Now, if Novel would please release a PHP 5.3 package for SLES 10 and SLES 11... thank you

At GIDS, you'll participate in hundreds of sessions encompassing the full range of Microsoft computing, Java, Agile, RIA, Rich Web, open source/standards, languages, frameworks and platforms, practical tutorials that deep dive into technical skill and best practices, inspirational keynote presentations, an Expo Hall featuring dozens of the latest projects and products activities, engaging networking events, and the interact with the best and brightest of speakers from around the world.
Start Date: 2010-04-20
Start Time: 08:00
End Date: 2010-04-23
End Time: 18:00

In a nutshell a Facebook group formed to put the 17 year old Rage Against The Machine Song "Killing In The Name Of" on top of this years British Christmas Charts.

Here's their official video

Click here to view the embedded video.

The video itself does not say very much, the information text next to it on the YouTube page itself is much better.

The X-Factor is a Music Chart TV Show much like the "American Idol" or the German "DSDS". In the last years, the winner of the X-Factor show has always been the number one hit for the British christmas charts.

Apparently people have enough of this. Hence they formed the Facebook group to push another song into the charts - Rage Against The Machine with Killing In The Name Of.

You can help their cause by buying a download of the song either on iTunes, Amazon and various other sites.

Currently the song in fact is number one in the British charts.

This is a wakeup call to everyone that is not yet convinced about the potential of social media to drive business. The potential is there. Now it is proven again.