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

Re: [leanagilescrum] Re: don't start what you can't finish

Expand Messages
  • Jose M Beas
    ... Sure, Rob. I agree with you (and I should rewrite my two scenarios) but my question is still unanswered. Are we allowed to split a user story to fill the
    Message 1 of 59 , Jan 20, 2009
    View Source
    • 0 Attachment
      2009/1/20 Rob Park <robert.d.park@...>:
      > Of course it all depends. A team of 8 that has an average cycle time (dev
      > only) of 4d per story... even 4h may be noise. But a team of 3 with an avg
      > cycle time of < 1d ... 2h could be useful. And even then it probably
      > depends how long is the iteration? 1w? 3w?
      > I assumed we're talking about some amount of available time that does /not/
      > feel like noise.
      > .rob.

      Sure, Rob. I agree with you (and I should rewrite my two scenarios)
      but my question is still unanswered.

      Are we allowed to split a user story to fill the remaining time
      available in a sprint? Do you recommend that practice? Is there any
      limitation to that?

      Thanks in advance,
      JMB
    • George Dinwiddie
      ... If the backlog items are largish, then I see no reason that a Kanban team wouldn t swarm over them. ... Either people are available to work on the story or
      Message 59 of 59 , Jan 22, 2009
      View Source
      • 0 Attachment
        Alan Shalloway wrote:
        > --- In leanagile@yahoogroups.com, George Dinwiddie <lists@...> wrote:
        >> Alan Shalloway wrote:
        >>> --- In leanagile@yahoogroups.com, George Dinwiddie <lists@> wrote:
        >>>> Alan Shalloway wrote:
        >>>>> --- In leanagilescrum@yahoogroups.com, George Dinwiddie
        > <lists@>
        >>>>> wrote:
        >>>>>
        >>>>>> Why can't you do it on every story? While most teams don't, I
        >>>>>> think it's possible on all but very tiny stories, which most
        >>>>>> teams don't have.
        >>>>> I like to swarm when you can, but a couple of reasons why you
        >>>>> can't:
        >>>>> 1) required people aren't available
        >>>>> 2) story content requires a linear approach
        >> >>
        >>>> Perhaps some actual examples would help. I don't think I've ever
        >>>> /really/ run into these situations, though often people jump to
        > such
        >>>> conclusions.
        >>> Type A scrum works off the product backlog. But the product
        > backlog
        >>> is only for one product. I have long said Scrum works fine for
        >>> this. I am talking about how to look at the problem of managing
        > all
        >>> of the products in an organization.
        >> OK. This conversation is getting a little confusing to me. When
        > you say,
        >>> Now, Kanban
        >>> is typically done in a way where things flow from one role to
        >>> another. Therefore, in typical Kanban I don't think swarming
        >>> occurs. But this doesn't mean you can't do team swarming in
        > Kanban.
        >>> I think you can have two general types of Kanban at the team
        > level.
        >>> The first is the normal (current) way of doing it where the work
        > goes
        >>> through the different stages and people pull (use Kanban) from
        > the
        >>> role before them. No swarming here.
        >> you specifically mentioned "at the team level."
        >>
        >> Do you intend that the team pulls work for a single product? Or
        > that
        >> the team pulls work for the highest priority item across all
        > products?
        >> Or that individuals pull work for the highest priority item across
        > all
        >> products? Or what?
        >
        > I meant Kanban at the team level by looking at the value stream from
        > the product backlog to the time the team produces the result. Kanban
        > often has a common backlog across products - and it's most effective
        > when it is used this way. But I was referring when Kanban teams pull
        > something from the product backlog.
        >
        >> In any event, if the team is pulling work, it seems to me to either
        >> be big enough to swarm over, or so tiny that we've devolved in
        >> having an omniscient project manager do a complete work breakdown
        >> and direct the workers as if they're just a pair of hands. But I'm
        >> only seeing these two possibilities at the moment. What is the
        >> third possibility that you're seeing?
        >
        > I thought I had said there were two types - not sure where you got I
        > said three. Remember, backlog items for a Kanban team doing
        > development (as opposed to support) are often bigger than items for a
        > Scrum team (since the sprint backlog can't contain more stuff than
        > you can do in a sprint - typically two weeks) while a Kanban cycle
        > can be much longer.

        If the backlog items are largish, then I see no reason that a Kanban
        team wouldn't swarm over them.

        >>>>> I like to swarm when you can, but a couple of reasons why you
        >>>>> can't:
        >>>>> 1) required people aren't available

        Either people are available to work on the story or it stops. If a
        largish story is completely blocked by the absence of one person, you've
        got an issue that probably blocks Lean, Agile, Scrum or Kanban. This is
        just no way for an organization of any size to work. Your statement,

        >>> Now, Kanban
        >>> is typically done in a way where things flow from one role to
        >>> another.

        indicates that the work process has devolved to an assembly line, with
        every bit of work involving a handoff from one person to another. This
        is a terrible way to work, in my experience. The worst effect is the
        communication loss and delays in those handoffs. Another effect is that
        doing this necessarily increases WIP, or else the other "stations" will
        be idle. Another subtle, but devastating effect is that the way work is
        done is almost impossible to change, since the workers have no control
        over the larger process, but only their "station" in the flow.

        >>>>> 2) story content requires a linear approach

        I find this one incredibly difficult to believe. I have never seen it,
        particularly for a largish story. I /have/ seen cases where people
        assume that they can only work on it in a linear fashion. This is
        merely ignorance, though.

        Anyway, that's the way it looks to me. Perhaps I'm misunderstanding
        your description of Kanban and why people normally can't or don't swarm
        on a story when using it.

        - George

        --
        ----------------------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------------------
      Your message has been successfully submitted and would be delivered to recipients shortly.