Ricardo Mestre’s Blog

Boris Gloger this (on his blog) about the role of a Scrum Master.

“That [struggling] is the measurement if you do it right. If it is easy you are failing in doing the job right. Changing the work behavior of a team, an organization or even a whole enterprise is not a piece of cake. It is terrible hard work.”

Exactly! And I must add: if you think that filling the role of Scrum Master will win you a popularity contest… think again.
So, only bad news in this post? Not really: if you’re doing right, nothing beats the feeling of “fighting the good fight”.
Have a nice weekend, everybody!

As promised to Cairo, here are the criteria I recommend for a Team to split user stories. Please take into account that none of this was invented by me: I’ve been following the criteria mentioned by Mike Cohn in his great book “Agile Estimating and Planning” - which is a must-have for anyone using Scrum.
So, after the proper attribution, here go the criteria:

When to split:

• A user story must be split when it is too large to fit within a single iteration. And why is that? Because it makes no sense that the Team commits (during the sprint planning) to a user story that it knows, beforehand, it will impossible to finish (according to the Team’s definition of “done”) during the sprint duration. That would be commiting to do the impossible, which must be avoided.

• When a user story is small enough to fit within a sprint, but it won’t fit within the sprint being planned because there isn’t room left. Again, this must be done in order to prevent over-commitment.

• It can be useful to split a large user stroy (an “epic”), if a more accurate estimate is needed. Why? Because we, humans, are much better estimators when we are estimating within the same order of magnitude.

How to split:

• Split a large user story along the boundaries of the data supported by the story. For example, the user story “As a user, I want to be able to enter my personal information” would be splittable into several small user stories, like “As a user, I want to be able to insert my name” and “As a user, I want to be able to insert my birthday” and “As a user, I want to be able to insert my phone number”

• Split a large user story based on the operations that are performed within the story. A good way to do this is split the story along the proverbial CRUD (Create, Read, Update, Delete) operations.

• Remove cross-cutting concerns (such a security, logging, error handling, etc.) and creating two versions of the story: one with and one without support for those cross-cutting concerns.

• Split a large user story by separating the functional and nonfunctional aspects into separate small user stories.

• Split a large user story in small stories, if those small user stories have mixed business priorities.

Hope it helps. Oh, and go get the book: it’s that good!

• Interesting post from Nathan Jamin, regarding Retrospectives in Distributed Scrum Teams
• Another interesting post from McLean (via Nathan Jamin), regarding Retrospectives

A real life example, during a work interview:

“Me: So, Scrum is an empirical method of managing projects.
xpto: So, it’s something random, right?”

Way wrong. There is a huge difference between: random and empirical.
Let’s start with the first one: the empirical method which is in the base of Scrum is not random - far from it. If you prefer, substitute the term “empirical” by “adaptative” - because that’s what’s done in continuous feedback cycles in Scrum: Inspect, Adapt, Do, Repeat, etc.
In Scrum, you have 3 cycles of feedback:
- every 24 hours, at the Scrum Daily Meeting
- every Sprint (2 to 4 weeks, in average), at the Sprint Review
- every Release (several Sprints)

So, it’s far from random. In fact, is much more reliable than the Waterfall methodology. Waterfall is a predicitive model - i.e., you pretend you have a magic crystal ball, in which you predict everything which is going to happen during the project(!). That sounds a lot more like random wishful thinking, IMHO.

To sum it up, in Scrum, you have an empirical/adaptive methodology instead of a predicitive one.

I’ve got another interesting question from Artur Martins:

“Which books I need to read in order to know how Scrum works?”

Nowadays, there are tons of books regarding Scrum. When I started to get some information regarding Scrum, I did a very common mistake: try to get my hands in all books I could manage to. Is that useful? Not really.

IMHO, the best thing to do is read the book that started it all: “Agile Software Development with SCRUM”, by Ken Schwaber and Mike Beedle. Some approaches stated in the book are a little dated nowadays, but it’s still the best place to start.

Then, if possible, get a CSM (Certified Scrum Master) course: I can recommend you the services of Boris Gloger - not cheap, mind you, but for sure he delivers!

Next step? Three next steps, in fact: Practice, Practice, Practice.

Only after that you’ll reap benefits from reading other books about Scrum, which deal with specific parts of applying Scrum.

So, how went the workshop at Barcamp Portugal ‘08? Great, thanks to a fantastic audience, which hanged tough for almost 4 hours(!) - it seems that my inital estimate was really way off :).

My big Thanks! to all the participants - it was a pleasure to be with you! Now I just have to recover my voice.

Please feel free to download the slides from the workshop here: scrum101

Next step after Hamburg? Well, really close to home - I’ll be giving a talk/presentation in Coimbra, Portugal, on the 3rd Edition of Barcamp. Curious about what is a Barcamp? Take a look here. The event is organized by those tireless guys at WeBreakStuff, whose work and “can-do” attitude I admire.

About the talk: it’s an overview of Scrum (what else?), with an estimated duration of one hour and a half - and it’s prepared for a maximum of 40 participants. And, of course, it’s free, as everything in Barcamps is.

Interested? Drop me a line, if that’s the case.

Hello again!

The PM Hamburg meeting was a success: the location (Café del Sol, Hamburg) was great - roomy, which adapted very well to our crowd of enthusiastic Project Managers.

My sincere “Thank You” to Bernd Oestereich, Christian Weiss and Stephan Koß - for organizing such a great event. I’ll do my best to be on the next edition, in Vienna!

I’ll be present on the offline meeting of PM forum from Xing.

Where: Hamburg, Germany - Café del Sol, Jenfelder Allee 80 a, 22045 Hamburg (link)

When: 15 Aug 2008, 07:00 pm — 11:45 pm (Berlin Time)

I’ve got a good question from Cairo Noleto, regarding Scrum, which I’ll answer here:

“In Scrum, a Team is always mapped in only one project. Is it possible to manage several projects with a single Team? That’s something that happens quite a lot in the real world, specially in small organizations. How does Scrum deals with it?” - Cairo Noleto, Add4 Comunicação, Brazil

One thing which is crucial in a correct Scrum adoption is to avoid (and that’s a part of the Scrum Master job) that the team is interrupted during the duration of a Sprint. If the Team members have their effort splitted over several projects, then their concentration will be interrupted and cut off several times per day!
For a Scrum approach, the right thing to do is change from a team such as:

Team A: 8 members, working in projects P1, P2 and P3

…to, for instance….

Team A: 3 members, working in project P1
Team B: 3 members, working in project P2
Team C: 3 members, working in project P3

More questions? Feel free to ask, to ricardomestre at fastmail dot fm.