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

26159Re: Break down product backlog problem

Expand Messages
  • woynam
    Jan 4, 2008
    • 0 Attachment
      Estimation is a means to an end, not the goal of iterative development.

      The driving force behind iterations is *feedback*. Even if a feature
      is incomplete after 1 iteration, we can gain valuable feedback. If the
      feature is off-track, it's better to discover it sooner, rather than
      later.

      Leo has the tough job of convincing the PM that there are aspects of
      the feature that can be completed in 1 iteration, such that the PO can
      assess the correctness of the approach taken. Is there something about
      the feature that is unknown? The reality is that even when everyone is
      convinced that the feature is well understood, something creeps up
      that was unexpected. You just don't know what you don't know.

      Mark

      --- In scrumdevelopment@yahoogroups.com, "an.narasimhan"
      <an.narasimhan@...> wrote:
      >
      > I do not think it is a waterfall practice. Even if one uses Waterfall,
      > features have to be broken down for better estimation. Estimation a
      > large chuck cannot be more accurate than estimating smaller chunks. This
      > principle appliles everywhere. Even testing would be much more effective
      > when features are broken down.
      >
      > If you can do a review of estimates and actuals for couple of cases,
      > maybe the PM may get convinced that it is better to break down features
      > for better estimation, testability etc.
      > Rgds-AN
      >
      > leo.ren@... wrote:
      >
      > > thanks Srinivas.I believe our feature can be broken down. but that PM
      > > doesn't want to break it down.
      > > that's the problem. he thinks it's a waste of effort to break it down
      > > and no value. I think he is used
      > > to waterfall(he is new PM from another company), although I try to
      > > convince him from risk and quick feedback aspects. but I failed.
      > >
      > > Best Regards
      > > Leo Ren
      > >
      > >
      > >
      ------------------------------------------------------------------------
      > > From: scrumdevelopment@yahoogroups.com
      > > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of ext srinivas
      > > chillara
      > > Sent: 2008ǯ1·î3Æü 19:04
      > > To: scrumdevelopment@yahoogroups.com
      > > Subject: Re: [scrumdevelopment] Break down product backlog problem
      > >
      > > Hello Leo,
      > > This sort of thinking that, things can't be broken, is mostly muddled
      > > thinking.
      > > If you are at a liberty to tell me/us what this feature is then mostly
      > > I can break it down for you.
      > > (contact me offline if you want to: ceezone@...
      > > <mailto:ceezone@...> )
      > > One argument you can use is:
      > > If you think about developeing any fucntionality (either fresh or an
      > > enhancement), as one codes, progress is made in steps. Some are
      > > insignificant, some othersmore significant and a few, very
      significant.
      > > At every significant step it is advisable to check in the code that
      > > "works". There are bound to be atleast a couple of significant (or
      > > very significant) stepsin a given week, let alone a whole sprint.One
      > > can also think about these as fucntional milestones. This milestones
      > > can be descibed as break points, and be used to breaking up the
      stories.
      > > Example: Booking a plane ticket online. (from a givenlist of available
      > > flights)
      > > Broken into
      > > First Sprint
      > > 1) Single person booking on single leg. (Standard rate, no discount or
      > > special fare), on a given date
      > > Second Sprint:
      > > 2)Two or more passengers (family)booked at the same time, single leg.
      > > 3) With special fares included
      > > Third Sprint
      > > 4) Multiple leg, multiple passengers (no break journey)
      > > Fourth sprint
      > > .... Break journey allowed.....etc ....
      > > so on.....
      > > I think this comunity has to develop detailed real world examples.
      > > cheerio
      > > Cheenie
      > >
      > >
      > > ----- Original Message ----
      > > From: "leo.ren@..." <leo.ren@...>
      > > To: scrumdevelopment@yahoogroups.com
      > > Sent: Thursday, 3 January, 2008 2:13:12 PM
      > > Subject: [scrumdevelopment] Break down product backlog problem
      > >
      > > Hi
      > >
      > > I encounter a problem when I convince one project manager when we
      > > break down product backlog.
      > > There is a feature, which can not be finished in one sprint, I suggest
      > > to break it down and finish
      > > Them within two sprints. But the PM doesn't agree with me, he thinks
      > > it's no value to do so. And
      > > He think we can re-schedule this special sprint to twice of one normal
      > > sprint duration. I think it's not good.
      > > We should keep the duration of one sprint to be same. But I can not
      > > convince him. Can anybody
      > > Help me? Or I'm wrong? Thanks.
      > >
      > > Best Regards
      > > Leo Ren
      > >
      > >
      > >
      > >
      ------------------------------------------------------------------------
      > > Now you can chat without downloading messenger. Click here
      > >
      <http://in.rd.yahoo.com/tagline_webmessenger_5/*http://in.messenger.yahoo.com/webmessengerpromo.php>
      > > to know how.
      > >
      >
    • Show all 14 messages in this topic