RE: [scrumdevelopment] Use Cases?
- My only problem with Use Cases or any other method of capturing and analysing requirements is that this activity is fundamentally a human-centric activity, done best as a face-to-face conversation, with demonstrations and 'look alikes' to help understanding. There are many ways to gain this understanding, including eliciting User Stories, developing Use Cases, doing Story Boarding, developing Usage Scenarios, Rich Pictures, JAD sessions etc. My most successful session with clients was when I used a cartooning approach, using stick figures in various colours, jagged roofed buildings to indicate factories, old-fashioned telephone line representations for communication lines, and so on. The senior clients present thought this was a wonderful way to explain my understanding of requirements, and get their input.How you actually record your findings as a specification is another matter too. Needing formal diagrams (with no potato shapes because that doesn't look formal enough) can be a huge waste of time, and when you need special training in how to present requirements and what are the diagramming and document structure rules also indicates over-kill to me. That does not mean I think there should be no documentation.I try to teach my students that they can / should treat the analysis and development activity as a drama that they must play all the roles in. Even play-acting a user sitting down at a terminal and logging in. Even a quickly drawn 'login screen' can be taped to the screen to help them think about the design of that, and then the processing. 'Wearing the user's hat' or 'standing in the user's shoes' is another way of expressing it. Some of my project groups maintain a story board, where hand-drawn screen formats are pasted up as they are identified, and then replaced by a print-out of the actual screen when it is developed. There are many visual representations possible, and useful.So, as a direct answer to the original question ... Scrum does not mandate any particular way of eliciting and recording requirements, beyond the recommendations of face-to-face conversation, regular stand-up meetings (where you can sit down if you really want to', sprint planning sessions, maybe even user story analysis, but collaborative activity and transparency overall. Working with these 'guidelines, I guess its up to you what you actually do. Just make sure it is effective, and 'lean' ... meaning, as simple as possible but no simpler, only what is absolutely necessary, only what contributes directly to project progress and successful outcomes.Regards,Roy Morien
Date: Wed, 3 Nov 2010 00:01:42 -0400
Subject: Re: [scrumdevelopment] Use Cases?Hi, Sakendrick,
On 11/2/10 10:32 PM, sakendrick wrote:
> Do use cases have a place in scrum? My intuition is that if a user
> story is written correctly, that should be enough to drive discussion
> and collaboration, and enough for the development of test cases. But
> is there a void between user stories and test cases that requires use
> cases since the user story only focuses on the "what"?
If you're /good/ at use cases (and my experience is most places aren't),
then I seen no reason why you can't continue to use them. Use cases can
be helpful in making sure that you've covered all the important flows.
They can also be terribly confusing to business people (and sometimes to
technical people, too).
You'll still want to come up with test cases that cover all the flows of
the use case, and often covering just a part of a flow. These can be
bundled in small groups (1 to 3 might be a good number) and used as the
acceptance criteria for stories.
> Curious what people are practicing... I've read several articles with
> mixed opinions on this - some state that user story and use cases are
> just different methods of communicating requirements or expectations
> (use one or the other), where as other say they are different animals
> and in some situations you need the detailed use cases.
In what situations would you need detailed use cases, and why?
Nov 15-16 Agile Testing Workshop in Orlando
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
- "Oh, I'm sorry, when I said I wanted it to 'take off like a helicopter,' I meant 'take off like a helicopter from a warzone, where we can carry troops and equipment.'
And there's the rub. The devil is in the details, and sometimes those details means we're off the mark (Harrier vs. Osprey) or things take much longer than anticipated (Osprey).
Someone else made a point here recently about how it's extremely important to a) get to the details, by having the CEO appoint a point person and b) make sure you loop in the CEO iteratively and intelligently (respecting his time) so he can head off any incorrect interpretation of his vision.
I'm not against vision, but a vision is not a "software requirement". Further, a vision is not easily testable, nor is a business requirement, because they often lack the key ingredient of system behavior that you can test against.