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

RE: [scrumdevelopment] Fixed iterations, unsure content

Expand Messages
  • Wolfgang Schulze Zachau
    I would have gone with the motto Do just enough . If the user story is ambiguous enough to allow for discovery of substantial extra work during the sprint,
    Message 1 of 2 , Aug 17, 2007
    • 0 Attachment
      I would have gone with the motto "Do just enough". If the user story is ambiguous enough to allow for discovery of substantial extra work during the sprint, then quite clearly the PO didn't fully grasp the story at the time of writing it. In waterfall that's a big problem. In Scrum it's normal. We can never know everything now that we will come to know in the future (there wouldn't be any future in that case). So my advice would have been: implement the original item and put the newly discovered work on the product backlog. It is then up to the PO to decide whether this needs doing in the next sprint or not.
      Many engineers suffer from the delusion that they think they know better (than the PO or the customers or the users) what will be needed in the future. There is always the temptation to over-engineer a product (not just in software). Don't fall for it. Do the simplest thing that will fulfill the original story.
      I would preserve spikes for stories where completely unknown territory has to be charted. Packing excessive slack into a sprint sounds like a "belts and braces" approach and smells of a lot of waste. If the PO doesn't understand a particular area, then maybe that specialist should sit with the PO and help him/her to write the additional user stories (instead of implementing them on her own).
       

      Regards,

      Wolfgang

       


      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of DoctorArtem
      Sent: 17 August 2007 12:55
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Fixed iterations, unsure content

      Hi all

      We are doing Scrum in a team that has several quite specialized
      members. I've got a question from one of the specialist that I am not
      sure how to answer.

      On the last retrospective team decided to commit only to the items
      they were "really sure" they can do. This specialist followed the
      agreed rules and committed to the product backlog item (more of a task
      in this case) she could do for sure. However, during the sprint she
      realized that the original item is only a part of what's really needed
      to improve. She could finish on time exactly what was agreed, but then
      later she would have to return to the same issue again. She decided to
      make the task in full now and then it has to be finished during the
      next sprint only. The situation is somewhat complicated because she is
      a specialist and the other team members can hardly help her. In fact
      they are already doing more, then the team committed, because they
      have some "free time", while the specialist cannot finish her task in
      full.

      The question from the specialist is what is the sprint useful for in
      our situation. It forces her to feel guilty, because of doing the
      quality work (i.e. doing the task in full).

      ------------ --
      What I was able to tell about the other teams having similar situation
      was:
      1. Whenever team feels the sprint commitment cannot be met, meet with
      PO and change the scope.
      - That won't work in our situation since PO doesn't really understand
      things in her area and fully trusts the team.

      2. Pack some reasonably big amount of slack into the sprint commitment
      - We might discuss it further, but as for now she feels she is too
      ambitious for it. Talking frankly to me it might also feel
      demotivating if at the end of the sprint I had to commit to very
      little work just in case of the potential problem

      3. Accompany every not-trivial backlog item with the "spike" item to
      research the real needed scope, complexity and the whole feasibility
      of a task.
      - Probably I failed to explain the spike concept well enough (any good
      links?) and anyway how can a person be confident about the scope if it
      decides (for a good reason!) to change the scope half-away?
      ------------ ----

      Sorry for the somewhat confused explanation. Heh, I am asking exactly
      because I am confused :)

      Every advice on the situation is very much welcome.

      Best regards,
      Artem.

    Your message has been successfully submitted and would be delivered to recipients shortly.