In convincing management of the benefits of working on smaller scopes in more iterations. Have you seen this make a difference in speed, quality or ability to adapt to change in requirements?
My team has been paying special attention to story size for the last few iterations and we've noticed several benefits of breaking down features into smaller stories:
- We are better able to judge how much we can get done in an iteration.
- We reduce doubt and uncertainty around a story by breaking larger stories down into small, well-defined stories. Doing so requires extra research and extra thinking upfront that pays off in the end.
- If something happens during an iteration that makes us unable to complete everything we scheduled, it's a lot easier to push off small stories that weren't started than to try and roll over parts of bigger stories to another iteration.
On the flipside, we have found it harder to swarm on smaller stories, but overall keeping the stories small allows my team to keep delivering completed features or parts of features more reliably.
There are a few:
- You get something sooner. Less = Quicker
- Your developers are more focused. 1 thing to think about, 1 thing to ponder, 1 thing to get right at a time. The more fragmented your focus the more mistakes / errors you will have.
- Each small sprint provides the ability to adjust priorities. In business this is critical, if they are committed to a single path for too long, you will have people trying to break in and say "can you just get my thing done on the side" ...
Selling it to business:
- Do you really want to be locked in for a long time?
- If client X jumps up and wants something new which will make you an additional $500,000, do you want to make them wait 2 weeks or 6 months?
Each feature has an ROI, which is the time it saves someone over the old way of doing it by the number of people doing X. Using this you can show that releasing small things sooner will have an ROI starting in 2 weeks and continually paying off more and more with each sprint.
The graph for the other case has "nothing for 6 months" then you start with the payoff at the high point, the saving is the difference between the 2 weeks and 6 months ... Plus the Risk involved in the 6 months is a much bigger gamble ... Haven't got a good ROI for it but discussions around risk usually have the desired result.
Honestly, "only over the long run"
I've seen huge benefits in being more predictable. (usually a team can get very predictable after 2-3 iterations). Once you have that down, you can take on (productively) the things people are noticing that slow the team down or cause quality issues.
Keep in mind that smaller iterations are -only- beneficial (IMHO) if you get -customer- feedback on the release at the end of the iteration. This is tough to understand until you have a customer who actually reviews and cares about the output, then you get a whole new understanding about requirements change and customer needs!