Kings and Servants - collaborate on the highest priority item

Some time ago I heard a great suggestion on how to view the idea of a team “swarming” on the top-priority item of the sprint backlog – i.e. how the team should see themselves with regard to who works on what story. As you know, following the priority order is a key mechanism in Scrum affecting your ability for timeboxing (having a flexible scope).

The tip was to view the people who work on the topmost priority item in the sprint backlog as “Kings”. Everyone else (consequently working on lower priority items) are Servants. All the Servants help the King(s) immediately as soon as the Kings need anything. Also, everyone wants to be King.

I’m working on spreading this idea in our organization. I had barely finished speaking to one of our teams before I found a printed picture of a crown put up on the Scrum Board alongside the top priority story :-).

Here's an image that I found with Google that you can print and put magnetic tape on the back of and use on your own Scrumboard(s).

Done or Complete? How to develop in iterations.

This topic is closely related to that of “Continuous Refactoring” which I am constantly nagging about. It is also related to “Definition of Done”, which is another favorite topic of mine :-).

When are you “Done”? The right answer is: When the Story meets the definition of done. Let’s say your Definition of Done says “Releasable”. So, the Story is done when it is Releasable. Great. But, wait… What does that mean, “Releasable”?

Coders are creative people. I touched this subject in my previous post “1-day remaining forever”. We want to do an excellent job, not just an average one. We want everything we ship to be just right, because bad solutions or sloppy code reflects directly on us and our abilities and creativity. So it’s easy to get stuck in the “almost done” mode, coz we want to polish that extra method or just fix that last design flaw or just rewrite that last class which was poorly written two years ago... So when faced with the goal line (i.e. the point when we’re “Done”) we really want to go to lengths to make sure everything we’ve done is really “ready” and fully thought through, and future-proof, and so on.

But the point I am trying to get to here is that there is a difference between “Done” and “Complete”. Every story needs to be Done in the sense that it fulfills our Definition of Done. But that does not mean “Complete”: it does not mean e.g. “future-proof” or “with architectural perfection”. Those states are achieved over several stories – over several iterations. This is why we call Agile development Iterative. So, think of it like this: “Done” is something we do with each story and each sprint, and “Complete” is something we reach over several stories and several sprints.

I’ve seen it several times; developers dig down into the system and try to solve problems that are of much less priority than the story at hand, e.g. by designing or preparing for some story that is much further down in the product backlog. This behavior builds dependency between stories, it breaks prioritization and it adds a lot of insecurity to the estimates. The proper approach is to focus on the immediate story only, and effectively staying within its boundaries. Trying to stay within the boundaries of a story requires discipline and (not least) a good understanding of Scrum and continuous refactoring.

To sum things up: Aim for “Done”, not “Complete”.

Until next time..!