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

Re: [XP] "What if team reluctant to take user difficult story in sprint?"

Expand Messages
  • 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 1 of 3 , Jan 11 2:39 PM
      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.