Re: [scrumdevelopment] Re: How did splitting stories above 5 helped us
- I've been doing this with a team recently. They want to do a green field rewrite of their mid-sized app and I've been brought in to lead a team to do that. I started with a 2 day onsite brainstorming roles and stories with the team and then we looked for epics (to us, anything over 5 days) and broke them down into stories of either half. one, two or five ideal person days. We never even put estimates on anything over five days which was just as well as stuff that had been informally described as "two weeks" varied from 8 man days to over fifty when we broken them down into 0.5-5 man day stories.I think it's a great approach for capturing more requirements and while I'm always reluctant to say how accurate an estimate is, I think we're starting to get a real sense of the scope of the project (one role started with 14 stories and by the end of this process had over 50!).Best Wishes,PeterOn Apr 25, 2009, at 6:07 AM, martagf_99 wrote:
- 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