I was about to write the same thing.
Tiago's article is interesting. I was surprised to read his stories
added up to less than the parent epics, as I usually see the total get
bigger as we split them (causing me to think Fibonacci instead of
exponential story points is a kind of self deception, though I clearly
haven't been able to explain this well yet). I visualize it like
Mandelbrot's fractal coastline that gets longer the closer you zoom in
I do think most teams should break stories smaller than they are
doing, before committing them to Sprints. But I also recall a Product
Owner who went to the opposite extreme, prematurely defining tiny
stories for the whole release during the first Sprint. Really, he had
no idea what would happen in the future. As the Product Backlog
itself is a kind of inventory, I'd prefer to wait until the last
responsible moment, which will vary based on how much precision you're
trying to get in the release plan.
On Apr 25, 2009, at 6:07 AM, martagf_99 wrote:
> We have been struggling with the issue of too big stories for a
> while. We have broken things down in the past, but not in small
> enough chunks, so from this sprint we're wrestling with splitting
> all of them in pieces no larger than 15 dev hours (we're focusing on
> one thing at a time; my guess is that when we do this correctly,
> test hours will then surface as an issue by themselves, and we'll
> move towards total hours rather than dev or test). The interesting
> thing for us is that it's had the opposite effect on estimates than
> for your team. When we've broken down things in smaller bits, we
> ended up with higher total estimates, because we uncovered a lot of
> uncertainty and missing details we didn't know about. It still is a
> good thing, because it has brought up a whole other bunch of issues
> about the detail of the stories that we already knew about, but we
> couldn't really back up. We'll have to deal with that next!
> --- In email@example.com, "tiagomjorge"
> <tiagomjorge@...> wrote:
>> Any comments?
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
> ! Groups Links