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

Spike user stories

Expand Messages
  • adam
    We re just starting scrum here. We re all [1] reading like scrum and user story books like mad. Where we identify a story that we (the devs) don t know enough
    Message 1 of 33 , Jul 25, 2006
    • 0 Attachment
      We're just starting scrum here. We're all [1] reading like scrum and
      user story books like mad.

      Where we identify a story that we (the devs) don't know enough to
      estimate we ask the customer (product manager) to have a spike to learn
      enough to then estimate the full story.

      In some cases this is to investigate a new 3rd party SDK and in others
      it might be to do performance profiling of our app to then estimates
      stories like (improve the X part of the product so it is comparable with
      product Y)

      Unfortunately the software manager (who is currently a kind of scrum
      master master) says "No, sprint deliverables must be working, tested,
      releasable features."

      Is he right? If so what should we be doing? I'm a bit lost and our scrum
      masters (including the software manager) don't get their scrum master
      training until September.

      adam

      1] obviously not all, there the usual bunch of people who basically
      aren't interested
    • Ron Jeffries
      Hello Marco, thanks for sharing your thoughts. On Monday, August 21, ... Yes. In my opinion, this is a sure sign that the story sizes are too widely varying,
      Message 33 of 33 , Aug 21, 2006
      • 0 Attachment
        Hello Marco, thanks for sharing your thoughts. On Monday, August 21,
        2006, at 9:26:38 AM, you wrote:

        >> Nonetheless, I like a story / feature burndown at the project level,

        > I agree with you if you managed to have fairly similar stories size/effort
        > wise but when you have stories of different size/effort a story/feature
        > burndown is misleading because it doesn't show you how much effort you
        > still need to put into the project if you want to deliver them all.

        Yes. In my opinion, this is a sure sign that the story sizes are
        too widely varying, and it's the thing to fix. Failing that, story
        points or some other pure estimate works well.

        > I spend at least one day every week discussing this same issue with my
        > current customer's managers. They like the total effort based
        > burnup/burndown but at the same time want a chart based on number of
        > stories and give to the latter one more weight. But they communicate
        > different messages! Example:

        > - 10 stories for the release of product X
        > - 5 of them have an estimate of 1 WUYU (whatever unit you use...)
        > - 5 of them have an estimate of 3 WUYU
        > - for various reason you cannot/don't want to split the bigger one down
        > - 1 of the 3 WUYU stories yet to be done

        > an effort based chart will show you that you still have 3 WUYU to do and
        > you can use your velocity to commit to a date while a story/feature chart
        > will show you only that you still have 1 story to do without an indication
        > of what that means.

        Yes, but ... when you have 4 stories this actually has an effect.
        When you have 40 or 100, it turns out that the count tracks the work
        units just fine. Law of large numbers hits quite early. Try it
        sometime.

        > You can have situations in which people are worried because you still have
        > 4 stories to do not considering they are small, 1 WUYU stories and, at the
        > same time, people not worried at all if you still have 2 story to do even
        > if it is a 3 WUYU one.

        Yes. I prefer to work with approximately two stories per programmer
        per week. In that case ... this becomes a non issue.

        Thus my "advice" is to use story count ... and do what has to be
        done to make it work, which usually means many stories of
        approximately the same size.

        Regards,

        Ron Jeffries
        www.XProgramming.com
        Find the simple path to what works and follow it,
        always looking for a simpler path. -- Patrick D. Smith
      Your message has been successfully submitted and would be delivered to recipients shortly.