Ricardo Mestre’s Blog

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!

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.

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.