Yesterday, we talked about product backlog. Ok, the person in charge of this document is the "product owner". In fact, it isn't a real person, but it's a role, which can be played by one or more people (Jaime and me for Battlewizard team). This role could be played by one person at parcial time (this is the typical scenario) or several people at full time (warning! SCRUM doesn't works with large projects, so if you detect this situation, think twice before applying it).

So product owner should have a clear idea about product to be built (Jaime have, I try to), he/she has to detect which features should be implemented and especially which features should NOT be implemented. It seems 45% of features never will be used. In the other hand, we have 80/20 rule, which sais more or less:

A lot of software developers are seduced by the old "80/20" rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies.

Unfortunately, it's never the same 20%. Everybody uses a different set of features. [...]

But that's another matter and should be told at some other time.

OK, as we said, product owner should have clear idea about project direction and keep up to dated and prioritized its product backlog. It's not about spend days and weeks analyzing and re-analyzing possible features, but it's working few hours or days in order to get most essential and basic features, suffice to begin working with first version (something could work).

This figure is similar than "client" role of eXtreme Programming, where it was the person in charge of collaborate with the team to write all user histories and decide which features will be implemented during next iteration.

Once version has been completed, product owner will review it together with dev team and see whether this version meets the expectations as he/she expected.

When product owner has completed its product backlog, then he/she will collaborate with development team to define the sprint backlog, so...
- ey! wait a minute! we don't know which "sprint backlog" is...
ugg... you're right... but I'm late, so next day we'll talk about sprints and sprint backlog (: