Loading ...
Sorry, an error occurred while loading the content.

Re: [scrumdevelopment] Re: How did splitting stories above 5 helped us

Expand Messages
  • Peter Bell
    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
    Message 1 of 4 , Apr 25, 2009
    • 0 Attachment
      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,
      Peter

      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!

      Thanks,

      Marta

      --- In scrumdevelopment@ yahoogroups. com, "tiagomjorge" <tiagomjorge@ ...> wrote:
      >
      > Any comments?
      > 
      > http://tiagomjorge. wordpress. com/2009/ 04/24/how- did-splitting- stories-above- 5-helped- us/
      > 
      > 
      > []s'
      > Tiago.
      >


    • Michael James
      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
      Message 2 of 4 , Apr 25, 2009
      • 0 Attachment
        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
        on it.

        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.

        --mj




        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!
        >
        > Thanks,
        >
        > Marta
        >
        >
        > --- In scrumdevelopment@yahoogroups.com, "tiagomjorge"
        > <tiagomjorge@...> wrote:
        >>
        >> Any comments?
        >>
        >> http://tiagomjorge.wordpress.com/2009/04/24/how-did-splitting-stories-above-5-helped-us/
        >>
        >>
        >> []s'
        >> Tiago.
        >>
        >
        >
        >
        >
        > ------------------------------------
        >
        > To Post a message, send it to: scrumdevelopment@...
        > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
        > ! Groups Links
        >
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.