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

156651Re: [XP] Re: Kanban vs Scrum

Expand Messages
  • Gustavo Cebrian Garcia
    Jul 3, 2011
    • 0 Attachment
      Jen, 1-8 ( are you talking about days??? points ???

      On 2 July 2011 18:45, Jeff Anderson <Thomasjeffreyandersontwin@...>wrote:

      > **
      >
      >
      > Another way to look at estimating in Kanban is this.
      >
      > Teams starting out with Kanban will typically have a lot of variability in
      > terms of work accepted by the system of work/team/ project/ whatever.
      >
      > Ie big, small, web page, data change, brand new application, and any
      > variation and combination .
      >
      > Teams overlaying Kanban on their existing methods will typically continue
      > to estimate as they previously did.
      >
      > As team progress, work accepted will typically become categorized into
      > better understood work types that have less variability. Ie team A might
      > typically work on java enhancements, emergency defects, and canned reports.
      >
      > This is similar to mature agile teams, ranges of estimates are quite low,
      > ie work is broken up into stories with points of 1-8 before work is started.
      > Work has low variability in terms of effort.
      >
      > The big difference between Kanban and other methods is that Kanban states
      > it's acceptable to not to estimate once you have low variability in work
      > coming in the door. You dont need to care wether you have 1 or an 8, just
      > make sure you broke up the work into stories that are between 1 and 8, call
      > them all 4, and assume that the average will hold. If it doesn't over time,
      > readjust the assumption to 5 or 3 or whatever your delivery metrics are
      > telling you.
      >
      > In other words the most important part of estimating is breaking up the
      > work into small pieces, once you've done that, the only reason to care about
      > difference in the small range is to provoke discussion. That's why I do 1-8
      > range planning poker, not because I care about the result, but because I
      > want the team to talk, and something about estimating promotes really good
      > conversation.
      >
      > Jeff Anderson
      >
      > agileconsulting.blogspot.com
      > http://twitter.com/thomasjeffrey
      >
      >
      > On 2011-06-29, at 1:38 PM, "Chris" <c-riesbeck@...> wrote:
      >
      > > To my mind, how hard something is shouldn't affect its priority. If the
      > product owner says something is important but the developers estimate it
      > will take a long time, then it's time to discuss splitting to get the most
      > bang for the least buck as early as possible.
      > >
      > > --- In extremeprogramming@yahoogroups.com, M��rton M��sz��ros <meza@...>
      > wrote:
      > > >
      > > > Hi Gustavo,
      > > >
      > > > To address your original question: Sometimes estimating does make sense
      > with
      > > > Kanban too. Giving the "product" an insight on the impact of their
      > > > requirement can help them in prioritizing upcoming tasks. It's
      > convenient to
      > > > use t-shirt sizes or something with a low resolution (beer sizes for
      > > > example). Having them requesting features that are relatively easy to
      > > > develop speeds up the process, makes the every-day life more impulsive
      > and
      > > > fun. Having large stuff stuck in for weeks may lead to focus- and
      > motivation
      > > > loss.
      > > > The important thing is - as in all agile implementations: collaborate.
      > Not
      > > > just with your fellow developers, but with the guys filling up the
      > input
      > > > queue.
      > > >
      > > > On 24 June 2011 12:41, Gustavo Cebrian Garcia <g.cebrian.garcia@
      > ...>wrote:
      > > >
      > > > > **
      > > > >
      > > > >
      > > > > OK, that is what I understood.
      > > > >
      > > > > What I get is that kanban is a visual process everyone can see the
      > flow and
      > > > > applies the concepts you just said. I think, when people say Kanban
      > vs
      > > > > Scrum,
      > > > >
      > > > > they mean whether they want to do timeboxing or not...
      > > > >
      > > > > Yes, it helped a lot, thanks.
      > > > >
      > > > > ( I got confused becasue I heard from some people they estimate even
      > when
      > > > > they do kanban )
      > > > >
      > > > > On 24 June 2011 12:25, Torbj��rn Gyllebring <torbjorn.gyllebring@...
      > > > > >wrote:
      > > > >
      > > > >
      > > > > > Hi Gustavo,
      > > > > >
      > > > > > the key point to remember is that "Kanban" isn't a process.
      > > > > > You apply Kanban to something, sometimes that something is Scrum.
      > > > > > My understanding is that most people that claim "we do Kanban
      > instead of
      > > > > > Scrum/XP/..." they really mean
      > > > > > "we have a unnamed process, to improve and explain parts of it we
      > use the
      > > > > > Kanban label".
      > > > > >
      > > > > > Kanban tells you to start with what you have, visualize the
      > workflow,
      > > > > limit
      > > > > > work in progress, manage flow and continuously improve.
      > > > > > You can't start with Kanban, equally little is guidance on
      > when/if/how to
      > > > > > do
      > > > > > estimation.
      > > > > > That said, many teams that apply Kanban to their process find that
      > the
      > > > > need
      > > > > > for estimation vanish because of the data and feedback provided by
      > the
      > > > > > visualization and reduced variation.
      > > > > >
      > > > > > Did that help?
      > > > > >
      > > > > > //tobbe
      > > > > >
      > > > > > On Fri, Jun 24, 2011 at 10:58 AM, Gustavo Cebrian Garcia <
      > > > > > g.cebrian.garcia@...> wrote:
      > > > > >
      > > > > > >
      > > > > > >
      > > > > > > Hello,
      > > > > > >
      > > > > > > I am a little bit confused with Kanban. I do Scrum, I practice
      > Kanban
      > > > > > > principles ( on progress, etc )
      > > > > > >
      > > > > > > When people say that they are doing just kanban and not Scrum,
      > how do
      > > > > > they
      > > > > > > estimate,
      > > > > > >
      > > > > > > Is there some kind of time-boxing with Kanban? There is no kind
      > of
      > > > > > > planning?
      > > > > > >
      > > > > > > Thanks.
      > > > > > >
      > > > > > > Gustavo.
      > > > > > >
      > > > > > > [Non-text portions of this message have been removed]
      > > > > > >
      > > > > > >
      > > > > > >
      > > > > >
      > > > > >
      > > > > > [Non-text portions of this message have been removed]
      > > > > >
      > > > > >
      > > > > >
      > > > > > ------------------------------------
      > > > > >
      > > > > > To Post a message, send it to: extremeprogramming@...
      > > > > >
      > > > > > To Unsubscribe, send a blank message to:
      > > > > > extremeprogramming-unsubscribe@...
      > > > > >
      > > > > > ad-free courtesy of objectmentor.comYahoo! Groups Links
      > > > > >
      > > > > >
      > > > > >
      > > > > >
      > > > >
      > > > > [Non-text portions of this message have been removed]
      > > > >
      > > > >
      > > > >
      > > >
      > > > M��rton M��sz��ros
      > > > *meza*
      > > > ------------------------------
      > > > skype: vsb-meza
      > > > facebook: http://facebook.com/vsbmeza
      > > > twitter: http://www.twitter.com/vsbmeza
      > > >
      > > >
      > > > [Non-text portions of this message have been removed]
      > > >
      > >
      > >
      >
      > [Non-text portions of this message have been removed]
      >
      >
      >


      [Non-text portions of this message have been removed]
    • Show all 23 messages in this topic