One of the main misconceptions of agile is that you should start working without planning, solely based on user stories.
I found plenty of usefull metaphors by comparing software to the (home/bridge) development projects.
If you imagine constructing a house based on user stories, you get something like this:
User story 1: User A enters the house by a big white door.
the developer builds a door (unattached)
User Story 2: When user A enters he finds a 4x4 Room A
the developer builds a closed room behind the door.
User story 3: Room A has a door on the left which leads to the living room, 3x5.
the developer “creates” a new door on room A (with a pickaxe) and builds a new living room.
(End of sprint 1 - semi house, no windows)
User story 4: Living room has 5 large windows
User Story N: Living room windows must face the sun at 9 AM
Bummer! now we need to refactor the whole house, rotating it to face the right direction
You get the point. Developing agile without first analyzing, “architecting” and building the foundations, things can get really hard in the mid term. Worst, if you’re not carefull, your house will be really funny.
Some of my conclusions to date:
- Prior to development, a satisfactory level of analysis must be conducted to ensure that the Architecture is well designed and understood. It is the Architect’s role ensure the right questions are made at the very beginning and to make sure that everybody understands that some things may not be changed by refactoring.
- User stories based development is good because it provides a “human” description of business rules, is great for managing work, ensures “near finished” work at any time and provides enough flexibility for changing direction as you see the work happening, ensuring value anticipation.
- User stories are good for business users to understand but sometimes lack completeness and clearness. It is critical to make sure they’re both complete and clear.