We've been talking about sprint backlog twice.
In one hand, while we're planning the sprint, we should make the sprint backlog, and in the other hand, during daily scrum, we should update its contents.

This is the theory, but... How are we making and updating our sprint backlog here at Unkasoft?

We base our work on well-known Juan Palacio's sprint template published time ago (with some final touches made by us).
We've been evaluating some others templates, but they didn't convince us due they was too complex.

In essence, this template is something as virtual board where we drop cards for tasks to be implemented and we move them when they're completed.
During daily scrum, we update each task, making a note of remaining hours to be completed, and the template will plot burndown charts for us.

Basically, the template has three sections:

Configuration:
We note down some general information about the project and the sprint, like number of days for the sprint, number of hours for each working day, kind of tasks (code, meeting, test, documentation...), task states, team members and holidays.

Data:
We write here all tasks extracted durint sprint planning, with estimated hours and the kind of task. For each task, we maintain the number of hours remaining to complete it. So, if one tasks isn't progressing, we'll see this number of days don't decrease, which is a bad thing.
Basing on this data and development speed (a factor between 0 and 1 we've introduced in the template), we can compute estimated release date, different for each day of the sprint. With this date, we can see whether we're behind schedule or not.
Another stuff we've introduced is a column with real hours for each task, which we fill when the task is completed. Although SCRUM doesn't propose this estimate-real hours control, we need it for our budgets and costs.

Charts:
Finally, basing on previous data, we can plot the typical burndown chart and another ones to see how tasks evolve, how release date fluctuates and the work load for each developer.
We could talk for hours about how you can interpret this charts. I recommend you this post about five signs of trouble in an iteration. We've suffered all of them (:
Also, there're more complex charts, in order to manage tasks introduced in the middle of the sprint.


Ok, it's been finishing... next day we'll talk about how we mix SCRUM with eXtreme Programming.

Last day we’ve been talking about how you can organize SCRUM sprints, but we skipped daily meeting subject.

But before we can start, we should introduce the Scrum Master role.
SCRUM suggests three roles: product owner, development team and Scrum Master.
The Scrum Master is that person who has the whole vision and the best way to apply SCRUM methodology inside your team. He/she isn’t the typical project manager or team leader, or the all-mighty-commander-boss. Scrum Master could be a person working at partial time, combining these tasks with another ones (perhaps he/she is the product owner or another programmer too), although at large projects, perhaps he/she is working at full time.
It’s important to say that Scrum Master has to be a person with enough power inside the company to make hard decisions.

Well, now we’re all introduced, so let’s continue…
The daily meeting (as well, called “daily scrum” referring to the typical rugby game movement) is the heart beating of the SCRUM project. The meeting is the place where the team is gathered, a sharing time where people talk about their progresses, doubts, ask for help and so on.
Thanks to this daily meeting, we’re averting typical end of project delays, because you’re watching the progress (or lack of) day by day.

Several dev teams I know, the project manager goes for each desk asking about the progress, or perhaps the programmer warns their manager when he/she is done.
Let’s remember SCRUM proposes auto-management, so here, the manager (Scrum Master) doesn’t review others’ work, but other team mates do.
It is important that the whole team can see whole project progress, instead of watch only him/her part. This will raise an identity feeling which could be considered the “SCRUM’s gasoline”. Without this feeling, the SCRUM project will stop as a car without gas.
And here I should remember you again: don’t try to use SCRUM at anywhere or with anybody. Choose carefully your team and your work environment.

Daily meeting shouldn’t last more than 10-15 minutes, in order to avoid typical endless meetings without a clear goal and subject. Here at Unkasoft, our daily meeting is very informal and last about 2 minutes because of our project has only two programmers (one of them is the Scrum Master too).
So don’t concoct more excuses in which you don’t have enough time to meet with your team.

SCRUM defines a “modus-operandi” more or less established. During the meeting, each team member should answer following questions:

1. What did you do yesterday?
2. What are you going to do today?
3. What do you need to progress?

In Jeff Sutherland’s blog (one of the two creator of SCRUM), he explain underlying reasons to these questions.

What did you do yesterday?
With this question we’re testing two things:

• Everybody is working on self-assigned tasks. As we already said, SCRUM works with auto-management, where each developer chooses which tasks he/she want to make.
• Whole team can watch project progresses. A good way of improve team’s morale is assuring each member can “taste” whole progress and see others members progressing. This can help people behind can faster his/her tasks.

At this moment, each programmer updates the sprint backlog in order to show remaining hours to complete each task of the sprint (next we’ll explain how sprint backlog is arranged and how you can work with it).

What are you going to do today?
Here, each team member assigns remaining tasks of sprint backlog. Neither team nor Scrum Master should force anybody to do one task. Why? Because nobody will know better than developer which tasks he/she will make the best and the fastest. Everybody will choose tasks according his/her knowledge and experience, so step by step, tasks will be assigned in optimum way without external intervention (pure chaos theory :)
As sprint progresses, hard tasks will be left. Then, Scrum Master could suggest, but never force.


What do you need to progress?
Sometimes, people in charge of other people forget his/her main duty: manage the environment in order to people can work faster and better. However, most bosses don’t apply this management, but he/she just command without remembering why he/she should command.
With this question, programmers raise a warning about blocking sides. The Scrum Master has to do all he/she can to solve theses problems.
Some typical problems could be:

• Programming: “I don’t know how I can use hardware acceleration in Java”. Ask for help to others team mates.
• Dependencies: “in order to implement this feature, I need rendering engine was stable”. Add new items to sprint backlog to assign these tasks.
• Management: “I haven’t network access” or “I delaying due every time I compile, I spend 30 minutes”. Scrum Master must solve theses problems.

Some problems could be solved adding more items to sprint backlog, but others don’t.
When your project was in a tight spot, these problems could be a ton. In that moment, Scrum Master should note down all problem and make a “impediment backlog”. From here on, main team priority is remove this impediment backlog. Each item will be assigned to team member or even out of team members (network admin, for example). Next day, this impediments backlog will be reviewed to remove solved problems and release blocked tasks.

Let’s follow with our SCRUM series… dealing with sprints.

We can say SCRUM’s sprints are something similar to XP’s iterations, although with several differences.

We could define a sprint as the total amount of time that development team has in order to implement, document and test a set of new functionality (this set is called “increment”). At the end of the sprint, we should have a ready-to-use, shrinkwrapped version ready to be delivered to any customer.

Typically, one sprint is split in three phases:

1.- Planning: a meeting with product owner together with development team with next goals:

• Set sprint’s duration: it shouldn’t last more than 30 days in order to don’t delay that stuff never should be delayed: the periodical deliveries. We usually work with 1-2 weeks sprints, but cheating, because we aren’t released “ready-to-use” versions, but internal versions (with lack of documentation, more exhaustive tests, etc.). Our failed subject is to achieve 3-4 weeks sprints (perhaps with one middle checkpoint) to get one ready to deliver version. Don’t worry Juan, we’re working on (:

• Choose a set of features to be implemented, in other words: the increment. The product owner will be choosing different user histories from product backlog and suggesting them to development team. At that time, development team should identify and estimate all concrete tasks necessary to implement chosen feature. Moreover, dev team should identify possible dependencies between features and warn to product owner. Let’s see it:
  
  - Product Owner (PO): well, I think we should implement the level editor’s undo/redo feature.
  - Development Team (DT): let’s see… this feature isn’t hard; we can use a mix of Command and Memento design patterns. It could be split in next tasks: a) create Command classes for different level editor’s actions. B) Create Memento class for level and c) give user interface to handle this. We can estimate them with 8, 5 and 6 hour respectively.
  - PO: OK, so we have assigned 19 hours of sprint. In the other hand, I’d like to use hardware acceleration for our levels renderers… We’ve realized it’s quite slow when we have a lot of objects.
  - DT: Wait a minute… that has been tried to do for isommetric renderers and we realized we should decouple the code before it. If you don’t do it, the change is to heavy and complex.
  - PO: OK, I had no idea about that. So… we have to refactor the code before implement hardware acceleration, right?
  - DT: Yes, we have to create new classes and test whole engines.
  - PO: All right. How many hours it will take?
  - DT: In one hand we have to refactor 3 or 4 classes and write unit tests, so let’s say two days. In the other hand we should research about VolatileImage class and apply that to all renderers classes, so 2 days more.
  - PO: OK, then we have 32 hours more which means we have assigned 52 hours.
  - DT: Something more?
  - PO: I’m, afraid rendering changes will take a lot of time to be tested for all handsets, so let’s reserve 2 days for testing and one more for update whole user documentation.

All these tasks will be noted down in one new spreadsheet called “sprint backlog”. We don’t note new features (user histories), but it turn into concrete tasks (refactor X, research Y and so on).
In sprint backlog we’re going to write the amount of hours remaining until each tasks was done.

2.- Implementation: once we’ve get our sprint backlog, we can start the development. Both parties (product owner and dev team) should agree they can’t add new tasks until sprint ends. If one new feature comes up, it will be added to product backlog and it will be taken into account for next sprint.
Everyday during sprint development, whole dev team will meet to review the progress and up to date the sprint backlog. This is the “daily meeting” and we’ll tackle it next day.

3.- Review: once the sprint has been completed, product owner and team will meet every other interested part (marketing people, customers, etc) and an informal demo will be done to show new functionality (called “increment”). During this meeting could arise one or more new features and them will be noted down at product backlog.

In the other side, dev team will meet themselves and will think about:

• What things went right and should be keeping up?

• What things went bad and could be improved?

For instance:
- Tony: we’ve failed with new renderers test.
- Johnny: yes, it was a sheer hell
- Tony: As soon as we have some free time, we should research how we can automate it.
- Johnny: yes, I note it down to add it at next sprint.
- Tony: By the way, undo/redo prototype feature went really good.
- Johnny: it’s true. It was a good thing that we spend a couple of hours writing a small prototype in order to prove whether Command and Memento design pattern works as expected.
- Tony: OK, next chances we can use prototypes too.

Next day we'll talk about daily work of one sprint and the daily meeting.

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 (:

OK, once we've been introduced to SCRUM, we're going to deal with several sides of this methodology, taking into account our own point of view and the way we've dealt with here at Unkasoft.

The First item we approached was Product backlog: it is the list of features to be implemented in the product we're creating. Theoretically, when all these features were implemented, the product will be done.

This step has been easy to implement for us, because months ago we've been maintaining a document (called "problems to solve") where we noted down all this stuff we'd like to add to Battlewizard. This document was expanded with our own experience, features requested from QA departament or from external companies using Battlewizard (like our early adopters GPM-e and Karonte).

This way, adapting to SCRUM has been as easy as convert our documento to a spreadsheet, adding all user stories subjects and a brief description using excel's comments. All these features have been arranged in four categories, in accordance to the need to be implemented: very high, high, medium and low.

And what’s all this stuff for? Because with this product backlog we’ll never forget one suggested feature and we can maintain and track a prioritized list of items pending to be implemented. Besides, this is the starting point when we're going to plan a new version.
Once a feature has been completed, it will be removed from product backlog and little by little this list will be decreased (ok, in fact I’ve never saw it decreasing, but it is always getting larger and larger. I hope one day things will change…)

Person in charge of maintain this document is called "product owner" and his/her main purpose is... ok, I think I've spoken enought for now, so next day we'll continue dealing with "product owner" figure.

This summer is been frantic! We're rearranging our dev team (one of them has already arrived and the other going to do it soon), released two games more (we can't say anything yet but you'll get news soon) and testing one new methodology for out project management: SCRUM.

It's a long time since we're using eXtreme Programming as development methodology, especially in our Battlewizard team, but planning, managent and tracking matters have been untidier than development side. So with Juan Palacio's help we're working out with SCRUM and now we're completing our sixth sprint (:

SCRUM is a auto-management team methodology, that is: there isn't a manager who cries commands and the others obey, but the team should be auto-managed.

Well, that's right and auto-management looks great but it's quite difficult to apply. Don't try to use this methodology at any company, because I know some of companies and people who will turn it in a true failure.
Just two days ago, Joel Spolsky has published a set of articles about team management, and he tells us there're three typical categories of management inside companies:

• Command and conquer: the boss tells what must be done and the others do it. This is the anti-SCRUM pattern. Team should be auto-managed, without external commands.

• External motivation: it's tried to motive people with rewards, bonuses, etc. It doesn't fit with SCRUM because we'll get people more concerned about getting prizes and bonuses instead of improve its own work.

• Indentity: it's tried to identify people with company's goals and philosofy, with a clear and fluent communication. When people understand whole company goals, it will be easy for them to make right decisions about their own work, without managers have to decide for them.

So first advice: do not try to apply SCRUM at any place. First obtain a good working environment and then everything will be easier.

Next, you have our experience about some SCRUM sides we're using here at Unkasoft:

• Product backlog
• Product owner
• Sprint
• Daily meeting
• Sprint backlog
• SCRUM and eXtreme Programming
  

In the late 70’s and 80, many companies defined their strategies moved by the ideas of great “gurus” as Kaplan and Norton, they were encouraged to seek exponential growth based on economies of scale. Everyone see sweet, the market of mobile game; want to get a piece of pie?

I found the courage to create a strategy map –inspired by the useful info América passed me-.
The main idea is to share it, and do it useful for all who wants be in –for skeptics of collaborations see the following post about 'Strategy of the Dolphin'-.

• The base, learn and growth perspective, always the engine for our company. The most important capital is the team people, those who work with us in this adventure, those who deliver all their creativity. Today’s business world suffers a lack of knowledge in their team members, and if a person in the team knows the company strategy, none is checking if it’s really moving on. Therefore, no measures no progress.

• The internal perspective has to consider the operational aspects as cost management. Seems ridiculous, but I know many companies forgetting this. Sadly in our market, the quality of a product is discovered by the user after sold it. In the meantime, comments of mobile games branded with poor quality are heard day to day –maybe we need to push the idea of preview/demo game-. Brands are necessary, people trust in them, but a bad use will go off the market. Innovation, the base of XXI century, we should look for new ideas and content for mobile games. All mixed with a good communication strategy will be the perfect salad for success.

• The customer perspective, with no doubts is the one who shows the outcomes of the work did. We could split it in two, first the Publisher or Mobile Op who publish the mobile game. The publisher is a role really optimized. They know exactly who, what and when in the mobile market, at least is what I’ve seen in Spain working with them. Publishers are looking for high quality and branded content, all delivery on time to get the wave of the movie or boor premiere. Also, the deployment of content was and is a tedious task, and hits the time-to-market. Whereas price is important, look for new revenue streams, extra downloable modules, ads in the games, and so on. In the other hand we have the end user –sorry, I know the Cluetrain Manifesto forbids these two words-. Indeed, end user wants a good easy to download content –forget to send 3 or 5 SMS to get it-, and of course a right-clear price.

• Cost Management has been dominant in the financial perspective. When cost management appear into practice, the use of tools is critical. For example, to reduce mobile game porting costs. Diversify revenue stream. And, for sure increase our revenues from non-traditional ways

We believe in one vision: be one of the best mobile game producers and not be the low cost. I know sounds as a cliché, but quality is the most important consideration; quantity is the least important. In line of that, keep improving shareholder value, shareholder trust in our idea and respond gracefully to this confidence.

Talking with some developer about mobile gaming, we always finished asking the same question: What is the difference between failing and success with mobile games? At least, the market and the technology limitations answer that question with coldness.

Nowdays, meeting with success needs of standing out with some of mobile games developed, where we must define “standing out” as selling success over production costs.

If we follow the market, we must look for the selling success inside popular brands and of course, into the cost saving in producing the games that need of moving the use of human resources to low cost countries. Then, success need of having a popular brand, create a game about that brand and having low production cost. Then, failing must be considering as the lack of popular brand and no way of porting games with a low cost mechanism.

As a message from the market and from technical limitations, we can consider this answer as the logical answer, but insufficient for us. We are going to change the success concept inserting new variables. Now, we think that success need of an automation of the porting games between mobile phones process, almost to the null cost. Also we will need of simple and easy games. We look for the developer comfort, distributor comfort, aggregator comfort, operator comfort and at least the fun for the user/player. If we are able to do and to package a funny game in two weeks with a 2.000 € production cost, and later we obtain revenues about 10.000 €, then we would meet with success because of the cost-effectiveness.

We don’t need of the popular brand; we need of adapting small companies, like us, to the market capacity. We need of process automation and need to parallelize our game developing. Making 10 casual games in a month with an average cost of 2.000 € per game, with revenues near to 10.000 € as objective per game, will meet the small developer with success.

Of course we will need of creative people for making funny and striking games. If we don’t have budget for advertising, leave the distributors and aggregators make their work moving the catalogs, with some downloads from each country we could be profitable.

We continue supporting quality games and popular brands games with quality, but while a small company can’t make a quality game with popular brands, they need of creating a catalog for getting money. You must automation the processes or ask for help to people like us that are automation our processes. It is a step of the way in this market.

The complete success, will be publishing a popular brand game with a low production cost.