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

"What if team reluctant to take user difficult story in sprint?"

Expand Messages
  • JeffGrigg
    In my LinkedIn Refactoring discussion group, Alex Z. asks, What if team members are reluctant to take user story difficult to implement which planned in a
    Message 1 of 3 , Jan 2, 2012
    • 0 Attachment
      In my LinkedIn Refactoring discussion group, Alex Z. asks, "What if team members are reluctant to take user story difficult to implement which planned in a sprint?"

      He says, "What if team members are reluctant to take user story difficult to implement which planned in a sprint? who is responsible for manage this issue? In the traditional project environment, project leader will assign difficult tasks to more experienced engineer."

      The LinkedIn discussion should be publicly visible, but requires membership to comment on LinkedIn. (I'll cross-post interesting comments from here, if needed.)

      http://www.linkedin.com/groups/What-if-team-members-are-81780.S.87253956

      Personally, I've never seen this problem happen. It makes me think that something odd is happening in their team; it seems like uncommon behavior -- unless team members are motivated in some odd way.
    • Charlie Poole
      Hi Jeff, If the team is reluctant to accept a story, then there is either something wrong with the story or something wrong with the team. Traditionally, the
      Message 2 of 3 , Jan 2, 2012
      • 0 Attachment
        Hi Jeff,

        If the team is reluctant to accept a story, then there is either something
        wrong with
        the story or something wrong with the team. Traditionally, the project
        leader assumes
        that it's the team and "convinces" the members to accept the story. We
        don't do that.

        If the team is reluctant, it's generally for good reason. So work with the
        team and
        figure out what is needed to mitigate the problem. It could be training,
        reduction
        in scope or some environment change.

        Charlie

        On Mon, Jan 2, 2012 at 9:26 AM, JeffGrigg <jeffreytoddgrigg@...>wrote:

        > **
        >
        >
        > In my LinkedIn Refactoring discussion group, Alex Z. asks, "What if team
        > members are reluctant to take user story difficult to implement which
        > planned in a sprint?"
        >
        > He says, "What if team members are reluctant to take user story difficult
        > to implement which planned in a sprint? who is responsible for manage this
        > issue? In the traditional project environment, project leader will assign
        > difficult tasks to more experienced engineer."
        >
        > The LinkedIn discussion should be publicly visible, but requires
        > membership to comment on LinkedIn. (I'll cross-post interesting comments
        > from here, if needed.)
        >
        > http://www.linkedin.com/groups/What-if-team-members-are-81780.S.87253956
        >
        > Personally, I've never seen this problem happen. It makes me think that
        > something odd is happening in their team; it seems like uncommon behavior
        > -- unless team members are motivated in some odd way.
        >
        >
        >


        [Non-text portions of this message have been removed]
      • George Paci
        ... There s a third alternative: the story could be a bad match for the team. For example, if my team had a task that involved creating a Flash animation.
        Message 3 of 3 , Jan 11, 2012
        • 0 Attachment
          On 1/2/12 12:41 PM, Charlie Poole wrote:

          > If the team is reluctant to accept a story, then there is
          > either something wrong with the story or something wrong
          > with the team.

          There's a third alternative: the story could be a bad match
          for the team. For example, if my team had a task that involved
          creating a Flash animation. That should have come up when
          doing estimation during the Planning Game, though: "OK, Ben's
          estimate for this card is one year. Can anybody do it faster?"

          > Traditionally, the project leader assumes that it's the
          > team and "convinces" the members to accept the story. We
          > don't do that.

          I couldn't agree more.

          > If the team is reluctant, it's generally for good
          > reason. So work with the team and figure out what is
          > needed to mitigate the problem. It could be training,
          > reduction in scope or some environment change.

          My instinctive reaction was that the story needs to be split (as you
          say, reduction in scope). Other possibilities:

          * There's a task T related to the story, but it's not clear to the
          team whether T is part of the story, or will be done as part of
          another story. (I guess you could call this "task ambiguity".)

          * The story was mis-estimated, and now everybody realizes it. The
          solution: re-estimate it knowing what the team knows now, then see how
          the difference in estimates affects the iteration plan, and re-plan to
          the extent necessary. Better the plan gets altered at the beginning
          of the iteration than at the end.

          * The story is really, mind-numbingly, soul-crushingly boring. These
          do exist (though your first instinct should be to automate away
          anything boring). Splitting it into many, many smaller parts and
          having each team member take some parts might help.

          * The story is hard to test. Either there are technical challenges to
          writing unit tests or acceptance tests, or the acceptance criteria are
          hopelessly vague, subjective, otherwise messy, or unknowable to the
          developers. Sometimes you can get around this by letting the Customer
          or a user directly input various important content (e.g. legal
          language, or written text that needs to meet some subjective
          standard). This may entail more development work, but less rework,
          frustration, and delay.

          * Nobody really believes the story will be used, thus sapping them of
          motivation to work on it. In that case, take a look at recent
          history, see if that's happened before, and address the process
          problems that let it happen.

          * Nobody really believes the story will be accepted when they're done
          with it. Again, look at recent history. Also, get as good a
          communication channel between the Customer/requester and the
          developers as possible, so they've got a clearer and more complete
          target to aim for.


          First and foremost you need, as you say, to work with the team: you
          can bring up all of the above as possibilities for the orphan story
          (in a safe, friendly, possibly manager-free environment), and then you
          need to really listen to what the team says about it. You may
          learn about a lot of heretofore invisible problems, big and small.

          --George gpaci at tiac dot net


          That sounds like a serious problem, so try to have that problem
          as soon as possible. -- Phlip
        Your message has been successfully submitted and would be delivered to recipients shortly.