Requirements through UI, use cases, confusion with planning
- 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 shippingpresumably
> sooner and a record of additional costs due to change requests, I'd
> try to hang my process improvements on that. Right now the
> go through a big internal planning process before talking to youat
> all. Then you have a big meeting, and they have to wait foroverlap
> everything they asked for to be developed. But suppose you
> the phases: they get a rough idea what they want and you startthe
> building the basics while they work out the details. By starting
> feedback loop earlier, they get a better product sooner. And byI just finished talking to my PM about this. He´s got many concerns.
> overlapping design and construction, they get faster time to market.
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
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
Any help would be truly appreciated!