ericlefevre

Once issue that we have with our customer is the definition of iterations. They want us to work with 6-week iterations, and release a previously-agreed scope at the end of the 6-weeks. The reasons for this according to them is that they need that long to run all the test cases they have (note that this development is a re-implementation of an application developed in Forte; all the specifications and test cases are already available and reasonably stable). At any rate, it does not break Scrum rules too much, so it should be alright.

Anyway, they do not mind us having shorter iterations. So we took the liberty to arrange the external iteration into three 2-week internal sub-iterations.

Problem is, how can we arrange the Iteration Backlog and still make things clear for the customer… and for us?

A first attempt has been to create new Excel tabs for each sub-iteration. So we would have 1 ‘backlog’ tab and 1 ‘burndown’ tab for sub-iteration 1, same thing for sub-iteration 2 and 3.
The issue that rose was that it became difficult for us (and for the customer) to understand what was going to be implemented in the external iteration. Say that the customer wants to check if a particular feature was going to be implemented. He would have to go to the first ‘backlog’ tab, then to each of the 2 other ‘backlog’ tabs. In practice, of course, he would stop after the first tab (I would too), and complain that we promised to do things and did not even list them.
As it turned out, the 2 other ‘backlog’ tabs did not contain this information. The person in charge of creating this Iteration Backlog had thought that things would be pulled from the Product Backlog during the Planning game for the other sub-iterations. Well, maybe so, but it is not making clear to the customer what we are hoping to implement in a given external iteration.

So I have suggested to rearrange the 3 tabs into a single one. The 1st tab would remain as it is. The 2nd ‘backlog’ tab would be copied just below it, in the same fashion as the ‘finer grained’ section in the Product Backlog, except that it would be called ’sub-iteration 2′ instead of ‘finer grained’. The 3rd ‘backlog’ tab would go further below. Maybe we could keep the labels ‘finer grained’ and ‘coarser grained’ as sub-titles for those sections, until we get in the middle of those iterations.

I think this allows everyone to see easily what is going on, while still capturing the idea that the later sub-iterations still need to be analyzed in the planning game.

On our project, there is a total of 21 tech people (plus managers and translators).
3 of us are onshore.
18 offshore.

You would expect this to lead to a natural split into 4 teams, right? 1 onshore, 3 teams of 6 offshore. Or maybe 3 Teams of 7 people, considering that we onshore are officially there for support (and not particularly for implementing features, though we do occasionally). This would nicely fit in the “7 plus or minus 2″ rule, right?

Incredible as it may sound, that is not what happened.
A couple of months after Craig introduced Scrum, I was wondering why there had been no mention of Feature Teams.

As it turns out, Craig *did* explain to them very clearly the benefits of splitting in feature teams. During the Retrospective Meeting, the Team (of 15 people, at the same) took the clear position that they did not want that to happen.

Craig’s opinion on this is that, in Scrum a Team takes its own decision. And if they do not want to follow a rule, then they shouldn’t be forced to.

Is it really so simple? For me, refusing to split in Features Teams is akin to flatly refusing to do Scrum at all. In the literature, I don’t really remember Ken Schwaber mentioning that it was optional, or even strongly recommended. It’s more like: “split the people in Teams, and then get them to choose tasks from the backlog”.

Now, I agree that once the team has decided *not* to split, then it is probably already too late. But why give them a choice at all? There are many other things they had no choice about, starting with using Scrum. I am convinced that, if they had been made to split in Teams, then they would have happily followed along without thinking twice about it.