How to split User Stories

When Bigger isn’t Better

Is bigger always better? When you believe the stories of Western culture, you might say: Yes.

• Bigger house,
• Bigger Car,
• Bigger Boat,
• Bigger Airplanes
• Bigger portions in the Restaurant,
• Bigger here and there…

It seems that bigger is the answer to everything.

But when it comes to agile software engineering, you soon find out that bigger is not always better.

• Bigger teams need more coordination and communication effort, and this slows the team down and even leads to subgroups and maybe conflicts.
• Bigger work packages delay releases, increase risks, and are harder to estimate and plan.
• Bigger specification documents need more time to write, they often have to be split into smaller sections later to understand them and distribute them to the team.
• Bigger iterations lead to bigger increments, and this leads to increased risks and delayed feedback.

I like the metaphor in which agile methods are compared to traditional approaches using boats.
An agile team is like a team on a sailing boat or a speedboat:

• they are sailed by a small team
• they are highly maneuverable
• they are fast