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

Requirements through UI, use cases, confusion with planning

Expand Messages
  • aacockburn
    I just peeled this question off the XP list, because it seems to fit the usability group. Note - I don t have any more context than this note, so I can t
    Message 1 of 1 , Nov 25, 2005
    • 0 Attachment
      I just peeled this question off the XP list, because it seems to fit
      the usability group. Note - I don't have any more context than this
      note, so I can't answer to that (Maybe Ron can).
      However, it still looks like an interesting situation to consider:
      -------------------------------
      Subject: Planning help needed

      In a recent dialogue about my company´s work with
      a client he wrote:

      > Given that they [the client] have measureable benefit from shipping
      > sooner and a record of additional costs due to change requests, I'd
      > try to hang my process improvements on that. Right now the
      presumably
      > go through a big internal planning process before talking to you
      at
      > all. Then you have a big meeting, and they have to wait for
      > everything they asked for to be developed. But suppose you
      overlap
      > the phases: they get a rough idea what they want and you start
      > building the basics while they work out the details. By starting
      the
      > feedback loop earlier, they get a better product sooner. And by
      > overlapping design and construction, they get faster time to market.

      I just finished talking to my PM about this. He´s got many concerns.
      As it stands we spend a week with our client on a workshop to get ALL
      the requirements - that is the goal although everyone recognizes that
      that will never fully come true.

      The workshops are very UI-centric, the requirements are explored by
      drawing on the whiteboard and brainstorming which in many ways is a
      good thing in. However, that gets my people and the client very hung
      up on EXACTLY how the UI should behave and they want to nail that down
      right away. In one respect this is understandable considering that a
      UI design firm takes sketches made in the workshops and creates the
      production screens. And the coordination of us, the client and the UI
      design firm is one of my PMs many concerns.

      Now, I have suggested that we change the Use Cases that come out of
      these workshop so that they only contain a brief description (like the
      description on a story card) and a list of acceptance criteria
      (tests).

      My PM has been mulling this over and is asking whether this won´t
      mushroom into a huge list of criteria, what with all the "popups,
      error boxes, flows through the use case, help texts, how some flash
      controls get "scratched", etc, etc..." Since I´m more book-learned in
      the XP practices rather experienced, I´m having some difficulty
      relating them to him. I think the fact that the Use Cases tend to
      cover a large area of functionality comes a lot into play here. Like:
      "Play Keno" looks pretty big to me! The client wants a whole game so
      what good can I tell my PM splitting this up will do?

      How can I alleviate his fears here? I´m not even sure I can alleviate
      my own fears! I´m not sure how to proceed.

      He has bad experiences with hashing things like these out after the
      workshop and in his view "that won´t work, is too slow and
      inaccurate"!?!?

      Any help would be truly appreciated!

      Best regards,
      --------------------------------------
    Your message has been successfully submitted and would be delivered to recipients shortly.